Re: Linux Core Consortium
* Brian Nelson ([EMAIL PROTECTED]) [041210 19:55]: > Yup. There's never been a sense of urgency. The RM's throw out release > dates and goals every once in a while, but no one seems to take those > seriously. Not true. (And, perhaps you noticed, the release team avoided to give specific days in the last time, and the timeline depends on a day N.) > And probably for good reason. Remarks like this _are_ driving the release back. > For the second straight > release, when we've gotten to a point that it seemed we were nearly > ready for a release, we then discover we have no security autobuilders. > The release then gets pushed back a few more months, while the plebeian > developers sit around twiddling their thumbs unable to help wondering > why the hell no one thought to set up the autobuilders in the 2+ years > we've been preparing a release. Be assured, the setting up the security autobuilders are a topic since I'm following the process of releasing sarge closely. Like e.g. in http://lists.debian.org/debian-devel-announce/2004/08/msg3.html which tells us that we need them for being able to freeze. Or, a bit later, http://lists.debian.org/debian-devel-announce/2004/09/msg5.html. This even tells: | The bad news is that we still do not have an ETA for the | testing-security autobuilders to be functional. This continues to be | the major blocker for proceeding with the freeze I don't think this mean that we suddenly discover it, but as other issues were more prominently blockers e.g. in July (like the toolchain), those issues were resolved back in September (and are still resolved now). Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Bug#282742: Move daily find run later
On 2004-12-08 Martin Schulze <[EMAIL PROTECTED]> wrote: > Andreas Metzler wrote: >> Anyway the solution seems to be overengineered for the problem at >> hand. I have yet to decide whether >> * I'll close the bugreport with "request denied" > Please don't do that but tag it wontfix instead if you "won't fix" this > bug report. Hello, My personal policy is to tag real bugs wontfix, but to close wishlist-requests, as it is a PITA for everybody involved to have the BTS cluttered with a great number of wishlist items. #282742 is somewhere in between, I'll respect your wish. cu andreas -- "See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf, fuhggvat qbja gur juveyvat tha. Neal Stephenson in "Snow Crash"
Re: Linux Core Consortium
On Sat, Dec 11, 2004 at 09:41:47AM +0100, Andreas Barth wrote: > * Brian Nelson ([EMAIL PROTECTED]) [041210 19:55]: > > Yup. There's never been a sense of urgency. The RM's throw out release > > dates and goals every once in a while, but no one seems to take those > > seriously. > > Not true. (And, perhaps you noticed, the release team avoided to give > specific days in the last time, and the timeline depends on a day N.) > > > And probably for good reason. > > Remarks like this _are_ driving the release back. No, they aren't. My remark is a symptom of the overall discouragement I feel with the release process, not a cause. Probably the biggest thing keeping sarge from releasing is the overall discouragement and disenchantment developers feel with the release process. > > For the second straight > > release, when we've gotten to a point that it seemed we were nearly > > ready for a release, we then discover we have no security autobuilders. > > The release then gets pushed back a few more months, while the plebeian > > developers sit around twiddling their thumbs unable to help wondering > > why the hell no one thought to set up the autobuilders in the 2+ years > > we've been preparing a release. > > Be assured, the setting up the security autobuilders are a topic since > I'm following the process of releasing sarge closely. Like e.g. in > http://lists.debian.org/debian-devel-announce/2004/08/msg3.html > which tells us that we need them for being able to freeze. Or, a bit > later, > http://lists.debian.org/debian-devel-announce/2004/09/msg5.html. > This even tells: > | The bad news is that we still do not have an ETA for the > | testing-security autobuilders to be functional. This continues to be > | the major blocker for proceeding with the freeze I was being sarcastic when I said we suddenly discovered it. Of course, it's been known we'd need a security autobuilder infrastructure for sarge since, uhhh, before woody's release. > I don't think this mean that we suddenly discover it, but as other > issues were more prominently blockers e.g. in July (like the toolchain), > those issues were resolved back in September (and are still resolved > now). Anyone, developer or non-developer, can help fix toolchain problems. However, the only people who can work on the testing-security autobuilders are ... the security team and the ftp-masters? What's that, a handful of people? With a bottleneck like that, isn't that a much more important issue? Besides, woody was release 2.5 years ago. In all that time, no one who had the power to setup the autobuilder infrastructure bothered to do it? Let's face it--that's a major fuckup. I'm not blaming you or anyone else in particular. We're all volunteers, we're all busy, we can't force anyone to do the work, etc. But we're not exactly lacking in manpower here. If those with the power didn't have the time to setup the infrastructure, surely over the course of 2.5 years we could have found someone out of the 1,000 or so developers we have that had the time and skill to do it. So why didn't that happen? -- For every sprinkle I find, I shall kill you!
amd64: ftp-masters questions (was: -= PROPOSAL =- Release sarge with amd64)
* Martin Michlmayr - Debian Project Leader ([EMAIL PROTECTED]) [040717 15:55]: > [AMD64 situation] > As to the > technical questions ftpmaster wants to raise, I'm quite disappointed > that they have not been posted yet because I was promised at DebConf > that it would happen soon. I've now asked someone I trust to find out > what these issues are exactly so hopefully progress will be made on > that soon. Is there any progress on this issue? Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
historic mails from me - please ignore
Hi, I seem to have un-frozen a couple of historic mails. Sorry for the noise, please ignore them. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Intel EM64T porting machine for Debian
* Martin Michlmayr - Debian Project Leader | * Chasecreek Systemhouse <[EMAIL PROTECTED]> [2004-12-10 20:56]: | > > agreed to set up the machine, host it for a while and give interested | > > developers access. This box is not a general .debian.org | > | > Is this by invitation only? | | Debian developers will not automatically get access (since it's not a | .debian.org box) so people need to request accounts. The machine will | be available to people who are interested in working on Debian's | AMD64/EM64T port. Stephen Frost is part of the AMD64 porting team and | if you're interested in helping out you should just get in contact | with him. (Having said this, Intel only just told me that they have | shipped the box, so it will take a while to arrive and get installed. | If you follow the debian-amd64 list, I'm sure Stephen will announce | when people can request accounts.) In addition, we have at least two other machines which are available to developers: pergolesi.debian.org -- admin is debian-admin (and all developers have accounts already) ravel.hpc2n.umu.se -- admin is Matthias Wadenstein and myself, drop either (or both) of us a mail to get an account. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor
* Thomas Bushnell BSG | That's a bad reason; if you applied it consistently you'd have to get | rid of frozen-bubble. everybody knows that frozen-bubble is useful for delaying Debian releases. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor
On Sat, 2004-12-11 at 00:13 +, Rich Walker wrote: > > It is outrageous to think that China's or Saudia Arabia's censorship > > regimes should somehow influence our decision making in the slightest. > > I believe the correct flame-inducing argument at this point is "tell > that to the first person tortured or executed for possessing a Debian CD > with hot-babe on it *who was not aware it was there*". If you live in a country with such draconian laws, then surely you ought to make sure as a matter of course about anything that you obtain from anywhere outside that country, regardless of the policy of the source with regards to including things that could get you in trouble. After all it is your life at stake. So, even if Debian were to take the position that they aren't going to include anything which might be illegal somewhere in the world[0] and that they made a genuine concerted effort, in good faith, to make sure that this was true, then I would suggest that since your life could be at stake you ought to make pretty damn certain for yourself that the CD isn't going to get you hung. Or perhaps you might like to trust that responsibility to some group whose aim is to produce a Debian CD that can safely be distributed in your country, but trusting that responsibility to the Debian developers as a whole, when your life may be at stake, would be pretty stupid of you. How many DD's do you think have the knowledge of, for example, Saudi law (not to mention incentive, time etc) necessary to make a guarantee to a person living in Saudi that a package won't get them hung? Crossed with the same knowledge for China? Crossed with the next place? You'd have to be an idiot to trust your life to those odds. [0] which I certainly don't think it should. I agree with Thomas on this one, it would be outrageous to pander to such countries. The fact that a DD is willing to package and distribute something under their local laws seem to me to imply that the package is at least safe to possess in the reasonable countries in the world, in that they won't hang you or otherwise throw the book at you for unwittingly possessing something which happens to be illegal in your jurisdiction. Ian. -- Ian Campbell When in doubt, lead trump. signature.asc Description: This is a digitally signed message part
Re: Bug#284642: ITP: dpkg-reversion -- change the version of a DEB file
also sprach Adam Heath <[EMAIL PROTECTED]> [2004.12.11.0259 +0100]: > Well, the plan is to make the dpkg-deb interface more formalized. What I > mean, is being able to use it in a filter, with plugging input and output. Thanks for the explanation. Yes, this is the sensible to do it. > Repacking and editting then become easy to do. I agree. In the mean time, I will have debedit be part of devscripts. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: Linux Core Consortium
* Bruce Perens:
> The Linux Core Consortium would like to have Debian's involvement. This
> organization has revived what I originally proposed to do as the LSB -
> to make a binary base for Linux distributions that could be among
> several distributions who would share in the effort of maintaining
> certain packages.
I don't think Debian should try to adopt an extensive, externally
specified ABI. For a few core packges, this may make some sense, but
not for most libraries.
Instead, proprietary software vendors should ship all libraries in the
versions they need, or link their software statically. I wouldn't
even mind if they installed something that approaches a stripped-down
distribution in a chroot jail (and just certify specific kernel
versions). Most of our software licenses permit this, so why don't we
use this advantage our system has over proprietary competitors?
My reasoning is as follows: If the ABI is externally specified (not by
Debian, not by upstream), we will in inevitably face ABI conformity
bugs. Because of the nature of such a bug, a fix requires an ABI
change. This means that most dependent packages will have to be
recompiled, and uploaded at roughly the same time ("libXXX
transition"), and it's always a big mess. Therefore, I fear that an
external ABI specification will incur substantial inconvenience for
our developers and users. For me, this is a bit too much for a
hypothetical group of users who currently cannot admit to using Debian
(and probably never will).
Re: Linux Core Consortium
* Michael Banck: > 2. GNOME succeeded for the desktop. Are there any proprietary COTS applications for GNOME where vendor support isn't bound to specific GNU/Linux distributions? Maybe GNOME is a good example of cross-vendor cooperation (but so is GCC), but would be quite surprised if this automatically leads to the uniformity that old-school ISVs desire.
Re: Linux Core Consortium
* Brian Nelson: > Anyone, developer or non-developer, can help fix toolchain problems. > However, the only people who can work on the testing-security > autobuilders are ... the security team and the ftp-masters? It's about infrastructure, so the security team is out (they are just users of this infrastructure, but they don't administrate it). Most ftp-masters, too, I believe.
Re: Linux Core Consortium
* Florian Weimer <[EMAIL PROTECTED]> [2004-12-11 12:36]: > > Anyone, developer or non-developer, can help fix toolchain problems. > > However, the only people who can work on the testing-security > > autobuilders are ... the security team and the ftp-masters? > > It's about infrastructure, so the security team is out (they are just > users of this infrastructure, but they don't administrate it). Most > ftp-masters, too, I believe. The archive tools are available (http://cvs.debian.org/dak/?cvsroot=dak) and there's a long TODO list. So while you might not be able to help set up the infrastructure itself, you could be involved in writing the tools running the infrastructure (and this might be a good way to become an ftpmaster later). -- Martin Michlmayr http://www.cyrius.com/
Re: Linux Core Consortium
On Thu, Dec 09, 2004 at 03:39:55PM -0500, Ian Murdock wrote: > You've just described the way the LSB has done it for years, which thus > far, hasn't worked--while there are numerous LSB-certified distros, > there are exactly zero LSB-certified applications. The reason for this > is that "substantially the same" isn't good enough--ISVs want *exactly > the same*, and there's a good reason for that, as evidenced by the fact > that while Debian is technically (very nearly) LSB compliant, there are > still a lot of edge cases like file system and package namespace > differences that fall outside the LSB that vastly complicate the > "certify to an ABI, then support all distros that implement > the ABI as defined by whether or not it passes a test kit" model. Well, my first question is why, irrespective of how valuable the LSB itself is to them, any ISV would choose to get their apps "LSB certified". The benefits of having one's distro LSB certified are clear, but what does an LSB certification give an ISV that their own internal testing can't? Or do you really mean there are no ISVs *writing* to the LSB? Secondly, is this merely conjecture about the needs of ISVs, or have you (or someone else involved with the LCC) actually talked to people who've said these things? If this initiative is truly a response to the needs of ISVs, it should be fairly easy to publically specify the LCC's scope up front so that Debian can decide whether there's any sense in trying to get involved. The fact that ISVs would be interested in package namespace differences at all worries me; it suggests to me that either the scope of the LSB simply needs to be broadened to meet their needs, or these ISVs are not in tune with the goals of the LSB as it is, and no amount of harmonizing package namespaces will address their real concerns. > I'm not knocking the LSB--by definition, the LSB codifies existing > standards, i.e., things everyone already agree with. The things > we're talking about here (package naming differences, network > configuration differences, all that) are clearly points of disagreement > between distributions (perhaps backed more by inertia than by anything > else). The LCC aims to complement the LSB by agreeing on a single set of > solutions for these edge cases, then by putting the necessary glue in > place to make sure whatever inertia or otherwise has propagated > the differences for so long doesn't remain an insurmountable obstacle. > And with enough mass, the edge cases become "stuff we agree on". Um, what's the concrete use case for a cross-distro standard network configuration interface? These are starting to sound like ISVs I don't *want* touching my Debian systems... -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Linux Core Consortium
* Steve Langasek: > Um, what's the concrete use case for a cross-distro standard network > configuration interface? VPN software, intrusion detection systems, software for CALEA support, centralized management software.
Bug#284978: general: libgmp segfaults on generating 48402688-bit random number
Thomas Womack <[EMAIL PROTECTED]> writes: Do you have libgmp2-dev or libgmp3-dev installed? I have libgmp2, libgmp3 4.0.1-3 and libgmp3-dev 4.0.1-3, so you're using later versions of all the relevant packages (indeed, since you're on amd64, on entirely different hardware) and the bug is still there. I've also reported it to [EMAIL PROTECTED] on general principle, though have heard nothing from them yet. I've just checked that this wasn't a stupid problem to do with missing mpz_init() commands; if you insert mpz_init(A); mpz_init(B); mpz_init(C); before the first mpz_urandomb() call, it still segfaults in the same place. Tom
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor
On Saturday 11 December 2004 01:13, Rich Walker wrote: > Thomas Bushnell BSG <[EMAIL PROTECTED]> writes: > > Rich Walker <[EMAIL PROTECTED]> writes: > [3] Non-US exists because export of strong crypto from the US is an > illegal act in the US. Hence, Debian has already accepted that > local laws trump idealism. actually non-us is a good example of letting packages into Debian despite it being illegal in certain areas. As discussed elsewhere in this thread this translated nobody is against giving people the option of classifying packages in Debian (into 'legal in China', 'not legal in China', ...), and giving people the option to easily exclude packages in a certain category. ). Provided off course that: the people that care about such classifications do the actual work (and not offload it to the rest of us) At least one mechanism for making classifications is available (debtags), though a mechanism for exluding packages from mirrors/CD's based on tags seams currently to be missing. -- Cheers, cobaco (aka Bart Cornelis) 1. Encrypted mail preferred (GPG KeyID: 0x86624ABB) 2. Plain-text mail recommended since I move html and double format mails to a low priority folder (they're mainly spam) pgpY3ZZiuVlPN.pgp Description: PGP signature
Processed: Re: Bug#284978: general: libgmp segfaults on generating 48402688-bit random number
Processing commands for [EMAIL PROTECTED]: > reassign 284978 gmp Bug#284978: general: libgmp segfaults on generating 48402688-bit random number Bug reassigned from package `general' to `gmp'. > * Tom Womack [Sat, Dec 11, 2004 at 11:39:37AM -]: Unknown command or malformed arguments to command. > > I've just checked that this wasn't a stupid problem to do with missing Unknown command or malformed arguments to command. > > mpz_init() commands; if you insert Unknown command or malformed arguments to command. > > Unknown command or malformed arguments to command. > > mpz_init(A); mpz_init(B); mpz_init(C); Unknown command or malformed arguments to command. Too many unknown commands, stopping here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Bug#284978: general: libgmp segfaults on generating 48402688-bit random number
reassign 284978 gmp * Tom Womack [Sat, Dec 11, 2004 at 11:39:37AM -]: > I've just checked that this wasn't a stupid problem to do with missing > mpz_init() commands; if you insert > > mpz_init(A); mpz_init(B); mpz_init(C); > > before the first mpz_urandomb() call, it still segfaults in the same place. Problem not reproducible with gmp 4.1.4-4. Have you tried setting no stack limit? signature.asc Description: Digital signature
Re: historic mails from me - please ignore
Heh. I read that as "histrionic". Twice. b.
Re: Debian package selection depending on user location/belief/society(was bug #283578 hot-babe (AGAIN :-)))
On Tue, Dec 07, 2004 at 09:49:57AM +, Will Newton wrote: [snip] > Not to point out the obvious, but "foul language" is dependant on the > language you speak, so most countries are unlikely to be offended by > the Linux kernel. Not to point out the obvious, but what is pornographic is dependant on the viewer, so most people are unlikely to be offended by the artwork in hotbabe... Regards: David Weinehall -- /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander (\ // Maintainer of the v2.0 kernel // Dance across the winter sky // \) http://www.acc.umu.se/~tao/(/ Full colour fire (/
Re: Linux Core Consortium
On Fri, Dec 10, 2004 at 01:42:57PM -0600, Gunnar Wolf wrote: > Adrian von Bidder dijo [Fri, Dec 10, 2004 at 04:38:10PM +0100]: > > > we don't exactly have a strong history of being able to pull off > > > timely releases > > > > Did Debian even try? > > > > I didn't follow the woody release too closely, being a Debian newbie at the > > time, so I don't know. But - this was my impression - from the start, > > sarge was prepared with the 'we release when we're ready' idea, which makes > > everybody feel that they have more than enough time. > > Yes, it did. Debian has long tried to shorten the release cycles, > without any success. That's the reason why Testing was introduced > (after Slink, IIRC). I got involved in Debian close to the Woody > release. We were quite optimist that Sarge would release in ~1 year Who was? Everybody with any sense knew that it wasn't going to happen. > There are many proposals to make Etch and future releases come out > sooner, please check them at > http://wiki.debian.net/index.cgi?ReleaseProposals Every single one of these falls into one of these four groups: (a) Give up (and maybe do something else entirely, like making unstable releases) (b) Split Debian into pieces, which we haven't tried before but we know won't make the pieces any easier to release (and what's the use of releasing a 'core' chunk early before there are any applications to run on it?) (c) Stuff that we've tried before and abandoned (like freezing unstable) (d) Stuff that isn't related to making releases faster -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- | signature.asc Description: Digital signature
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor
On Sat, Dec 11, 2004 at 01:24:32PM +0100, cobaco (aka Bart Cornelis) wrote: > On Saturday 11 December 2004 01:13, Rich Walker wrote: > > Thomas Bushnell BSG <[EMAIL PROTECTED]> writes: > > > Rich Walker <[EMAIL PROTECTED]> writes: > > [3] Non-US exists because export of strong crypto from the US is an > > illegal act in the US. Hence, Debian has already accepted that > > local laws trump idealism. > > actually non-us is a good example of letting packages into Debian despite it > being illegal in certain areas. Not really. The rest of the explanation for non-US is that those packages weren't illegal to USE in the USA, but were illegal to EXPORT. We don't have a section for packages that you aren't allowed to have, or aren't allowed to use. I'm all for omitting hot-babe just because it's more cruft. How many CPU monitors can we possibly use? I'm not too concerned about where it's legal for adults to use it. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: LCC and blobs
Brian Nelson <[EMAIL PROTECTED]> writes: > Matthew Palmer <[EMAIL PROTECTED]> writes: > >> On Fri, Dec 10, 2004 at 01:20:32PM +0100, Marco d'Itri wrote: >>> On Dec 09, Bruce Perens <[EMAIL PROTECTED]> wrote: >>> > I have been thinking about the blob problem for a while. I propose to >>> > remove blobs from the driver, and store them as files in initramfs (the >>> > kernel-internal filesystem created by the stuff in /usr/src/linux*/usr) >>> > or initrd.img. At boot time, the drivers would look for the blobs and >>> >>> You may want to take a look at debian-legal, because some people there >>> think that even free drivers for hardware devices which need an >>> externally loaded firmware are not acceptable for main. >> >> I presume you're referring to drivers which are useless without a non-free >> firmware blob. We should treat them exactly the same way as any other Free >> software which is useless without some non-free component, and stick it in >> contrib. > > Then we might as well remove the whole kernel from main, since most > devices depend on a non-free firmware blob to operate. Why does it > matter if that blob is stored on the device itself in EPROM or loaded by > the kernel? The end result is absolutely identical to the user. Because the GPL says so. Distribution of firmware binaries under GPL is just not legal. If you say the kernel violates the GPL because it depends on firmware in the hardwares eproms that is like saying Debian violates the GPL because it depends on non-free CPUs. That way lies insanity. Please go back and read the various mails about firmware blobs. > If we choose not to distribute non-free firmware blobs, then fine. I > still don't see why it has any effect on the device driver though. For 99% it doesn't have any effect. The number of drivers realy needing the blob is very small. > -- > For every sprinkle I find, I shall kill you! MfG Goswin
Re: LCC and blobs
Brian Nelson <[EMAIL PROTECTED]> writes: > Ron Johnson <[EMAIL PROTECTED]> writes: > >> On Fri, 2004-12-10 at 15:21 -0800, Brian Nelson wrote: >>> Matthew Palmer <[EMAIL PROTECTED]> writes: >>> >>> > On Fri, Dec 10, 2004 at 01:20:32PM +0100, Marco d'Itri wrote: >>> >> On Dec 09, Bruce Perens <[EMAIL PROTECTED]> wrote: >> [snip] >>> >>> Then we might as well remove the whole kernel from main, since most >>> devices depend on a non-free firmware blob to operate. Why does it >> >> Most ? > > I'm no hardware expert, but I assume all ethernet cards, wireless > chipsets, and SCSI cards do. At least that's true for all of the > hardware I have... > >> Or are you stretching beyond reason, to include stuff like the >> BIOS, which isn't in the kernel? > > If it made any sense at all for a mainboard's BIOS to loaded by the > Linux kernel at boot time with a non-free firmware blob, the current > consensus (on debian-legal anyway) seems to be that Debian would not > support it. Period. The drivers for it would have to go in contrib. > > As far as I'm concerned, distribution of the firmware is the > manufacturer's realm. Whether the manufacturer distributes it on an > EPROM on the device itself, or on a CD shipped with the device, or just > provides it for download from a website, I don't care. That's their > decision. Debian should not care one bit how the firmware is loaded on > the device, and the method used should not dictate whether a driver is > DFSG-compliant. It doesn't. What matters is if the firmware itself is distributable at all and if it is DFSG-compliant. How the firmware is loaded matters only for practical reasons (assuming non DFSG-compliant, non GPL blob): buildin into the kernel -> kernel becomes undistributable module to be loaded -> module goes to non-free firmware loaded from extra file -> firmware goes to non-free Since many drivers work without the firmware and the firmware only fixes bugs in some revisions or adds extra features it would be best if the driver optionaly loads firmware from an extra file. That way the driver can stay in main and people without the buggy revision or that don't need the extra features can still use it, e.g. in Debian-Installer. Think about it, if the driver works well enough to download the firmware file from the manufacturers cd or website (or even from debian) then all is well. > As for whether Debian would actually distribute the firmware blobs in > main, I would prefer that we do. It can be a real pain installing > Debian on a system in which I have to retrieve the firmware from an > external source. It's only hurting the end-user by making them jump > through more hoops to install Debian, with no obvious benefit. However, > there seems to be a strong movement to make Debian 100% free down to the > last bit. Reversing this movement is another much more controversial > issue. If the firmware is distributable and meets DFSG then it will be in main. This would probably be easiest under a BSD license which means using an extra file in the initrd to be loaded by the driver. > -- > For every sprinkle I find, I shall kill you! MfG Goswin
Re: add Date: field to Packages files
Adam Heath <[EMAIL PROTECTED]> writes: > On Fri, 10 Dec 2004, Santiago Vila wrote: > >> On Sat, 11 Dec 2004, Dan Jacobson wrote: >> >> > Say, perhaps a "Date:" field could be added to Packages files. >> > I mean even dog food has the date stamped on it these days. >> > Even my crumby message has a Date: field. >> > Sure, as your eyes scan the MD5sum: field, the package's DNA is >> > registered in your brain. But us old fashioned types would still like >> > a Date: field. >> > > Well Jacobson, the date can be clearly seen at >> > > http://.../pool/n/norbowitz >> > But Mom said no more searching the web for dates, so now I'm offline. >> >> Even offline, files have time stamps in most modern filesystems out there. >> Just remember to keep it when you download the Packages files, as it's >> usually as available as the file itself. > > Timestamp of the .ar members. The timestamp would not reflect when the file was added to testing for example. >From what I heard adding timestamps in the DAK would be difficult (needed for Packages file sorted by date of entry). But feel free to pick up the DAK cvs (or debs from the ITP) and patch it in. MfG Goswin
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor
On Saturday 11 December 2004 14:28, Hamish Moffatt wrote: > On Sat, Dec 11, 2004 at 01:24:32PM +0100, cobaco (aka Bart Cornelis) wrote: > > On Saturday 11 December 2004 01:13, Rich Walker wrote: > > > Thomas Bushnell BSG <[EMAIL PROTECTED]> writes: > > > > Rich Walker <[EMAIL PROTECTED]> writes: > > > > > > [3] Non-US exists because export of strong crypto from the US is an > > > illegal act in the US. Hence, Debian has already accepted that > > > local laws trump idealism. > > > > actually non-us is a good example of letting packages into Debian > > despite it being illegal in certain areas. > > Not really. The rest of the explanation for non-US is that those > packages weren't illegal to USE in the USA, but were illegal to > EXPORT. We don't have a section for packages that you aren't > allowed to have, or aren't allowed to use. point taken, make that: non-us is a good example of letting packages into Debian in a way that avoids it trumping local laws. -> if it's illegal to ofer it on don't offer it there, but keep it elsewhere > I'm all for omitting hot-babe just because it's more cruft. > How many CPU monitors can we possibly use? I'm not too concerned > about where it's legal for adults to use it. If we have a DD wanting to package and mantain some cpu-monitor, then we obviously have at least 1 person who: 1) thinks the package is worthwhile 2) is willing to do the work to support it as part of Debian Given that on what basis do we decide which cpu-monitors[1] meeting the above we allow in, and which we don't? First x of any category are allowed, is not a good solution IMHO (and definately less then ideal). Moreover why should we decide any such thing? Why should we not offer software for which some DD meets 2) above? It simply gives our users more options, which (IMHO) is a good thing. [1] or text-editors, or MTA's. or ... -- Cheers, cobaco (aka Bart Cornelis) 1. Encrypted mail preferred (GPG KeyID: 0x86624ABB) 2. Plain-text mail recommended since I move html and double format mails to a low priority folder (they're mainly spam) pgp3rhgQnS7YZ.pgp Description: PGP signature
Re: amd64: ftp-masters questions
Andreas Barth <[EMAIL PROTECTED]> writes: > * Martin Michlmayr - Debian Project Leader ([EMAIL PROTECTED]) [040717 15:55]: >> [AMD64 situation] >> As to the >> technical questions ftpmaster wants to raise, I'm quite disappointed >> that they have not been posted yet because I was promised at DebConf >> that it would happen soon. I've now asked someone I trust to find out >> what these issues are exactly so hopefully progress will be made on >> that soon. > > Is there any progress on this issue? > > > Cheers, > Andi This seems to be one of your unfrozen mails (1. Aug, huh?). But it is still as valid as back then. MfG Goswin
Re: LCC and blobs
On Dec 10, Matthew Palmer <[EMAIL PROTECTED]> wrote: > > You may want to take a look at debian-legal, because some people there > > think that even free drivers for hardware devices which need an > > externally loaded firmware are not acceptable for main. > I presume you're referring to drivers which are useless without a non-free > firmware blob. I know about no drivers which are useless without a non-free firmware, while I know about a huge number of hardware devices which are useless without a non-free firmware. -- ciao, | Marco | [9701 brFkyuAiot0mo] signature.asc Description: Digital signature
Re: LCC and blobs
On Dec 11, Brian Nelson <[EMAIL PROTECTED]> wrote: > If it made any sense at all for a mainboard's BIOS to loaded by the > Linux kernel at boot time with a non-free firmware blob, the current > consensus (on debian-legal anyway) seems to be that Debian would not > support it. Period. The drivers for it would have to go in contrib. I did not notice there was a consensus on this. -- ciao, | Marco | [9702 sfQB19rBNbXVc] signature.asc Description: Digital signature
Re: LCC and blobs
On Dec 11, Goswin von Brederlow <[EMAIL PROTECTED]> wrote: > Because the GPL says so. Distribution of firmware binaries under GPL is > just not legal. I do not believe that this is obvious. I understand that FSF disagrees, and considers firmwares to be just "data". > For 99% it doesn't have any effect. The number of drivers realy > needing the blob is very small. Not so small: the drivers for most WiFi network adapters, many bluetooth adapters, all USB DSL modems, most (all?) DVB receivers, most 3D video cards are just the ones I can think about right now. -- ciao, | Marco | [9703 ilLqSQlwJUtvw] signature.asc Description: Digital signature
Re: charsets in debian/control
Hello. Paul Hampson: > The email address isn't important, since > that has to be a subset of ASCII anyway. Are the Unicode-encoded domain names supported in (modern) browsers only? I can surf to http://ł.pl/ (with, e.g., Firefox) - can I send mail to [EMAIL PROTECTED], or should I always use the [EMAIL PROTECTED] equivalent, as the Unicode in domain names is restricted to WWW only? Cheers, -- Shot -- There's a difference between random people with stripy jumpers, and a respected scientist with a reputation. -- Steve Kitson, ucam.chat http://shot.pl/hovercraft/ === signature.asc Description: Digital signature
Re: charsets in debian/control
On Dec 11, "Shot (Piotr Szotkowski)" <[EMAIL PROTECTED]> wrote: > I can surf to http://?.pl/ (with, e.g., Firefox) - can I send mail to > [EMAIL PROTECTED], or should I always use the [EMAIL PROTECTED] equivalent, as > the Unicode in domain names is restricted to WWW only? It depends on your MUA. With mutt you can send mail to internationalized domain names without needing to type the ASCII encoding. -- ciao, | Marco | [9705 svftIaGWGM8aU] signature.asc Description: Digital signature
Re: LCC and blobs
[EMAIL PROTECTED] (Marco d'Itri) writes:
> On Dec 11, Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
>
>> Because the GPL says so. Distribution of firmware binaries under GPL is
>> just not legal.
> I do not believe that this is obvious. I understand that FSF disagrees,
> and considers firmwares to be just "data".
Would you accept a patch for ppp of the form:
char data[] = { 0x17, 0x23, 0x42, ...};
...
*(int (*)(int))data(fd);
After all, it is just data.
The FSF also things the GFDL is free, nothing new there. I also highly
doubt even the FSF would consider a file stating "DO NOT DISTRIBUTE"
as being GPL compatible because it is "just data". And some of the
files in question in the kernel do.
>> For 99% it doesn't have any effect. The number of drivers realy
>> needing the blob is very small.
> Not so small: the drivers for most WiFi network adapters, many bluetooth
> adapters, all USB DSL modems, most (all?) DVB receivers, most 3D video
> cards are just the ones I can think about right now.
I don't know about WiFi or bluetooh but the usb dsl modems seem to
work fine with e.g. eagle-usb-* packages.
Description: Data for Eagle USB ADSL modems
This package provides the DSP code needed to use the USB ADSL modems
featuring the Eagle chipset. This includes the Sagem [EMAIL PROTECTED] 800
modem.
(see where it says _code_ and not data) The usb-dsl stuff seems to be
external already so nothing changes there.
And I haven't heart of any 3D video card that _requires_ extra
firmware to work at all. It is true that you need extras to benefit
from 3D but that doesn't make them non-functional. 2D support is good
enough to install extra modules. It might be more work but there is no
requirement for tainting the main kernel image with non-free 3D
drivers.
MfG
Goswin
PS: I was going by the list of troublesome files posted month ago,
maybe that was incomplete but it wasn't overly long (comparted to
kernel size).
Re: LCC and blobs
[EMAIL PROTECTED] (Marco d'Itri) writes: > On Dec 10, Matthew Palmer <[EMAIL PROTECTED]> wrote: > >> > You may want to take a look at debian-legal, because some people there >> > think that even free drivers for hardware devices which need an >> > externally loaded firmware are not acceptable for main. >> I presume you're referring to drivers which are useless without a non-free >> firmware blob. > I know about no drivers which are useless without a non-free firmware, > while I know about a huge number of hardware devices which are useless > without a non-free firmware. > > -- > ciao, | > Marco | [9701 brFkyuAiot0mo] So the drivers without the firmware are usefull (i.e. make the hardware work) but the hardware doesn't work without firmware (i.e. make the driver fail)? You contradict yourself. MfG Goswin
Re: amd64: ftp-masters questions
* Goswin von Brederlow <[EMAIL PROTECTED]> [2004-12-11 15:17]: > > Is there any progress on this issue? > > This seems to be one of your unfrozen mails (1. Aug, huh?). But it is > still as valid as back then. My recollection is that all technical concerns were addressed and that the port would go in after the mirror issues will be sorted out (which will happen some point after sarge). -- Martin Michlmayr [EMAIL PROTECTED]
Re: charsets in debian/control
On Sat, 11 Dec 2004 16:08:12 +0100, Shot (Piotr Szotkowski) wrote: > Hello. > > Paul Hampson: > > > The email address isn't important, since > > that has to be a subset of ASCII anyway. > > Are the Unicode-encoded domain names > supported in (modern) browsers only? > > I can surf to http://ł.pl/ (with, e.g., Firefox) - can I send mail to > [EMAIL PROTECTED], or should I always use the [EMAIL PROTECTED] equivalent, as > the Unicode in domain names is restricted to WWW only? Interesting question. Quick check. Not restricted. Of course you have to use ACE (the ASCII Compatible Encoding defined in RFC3490) in transit (SMTP commands and message headers) but MUAs may (and at least some indeed do) accept/display the decoded form. aptitude search '~D^libidn' shows many apps at least linked with the IDN library. -- Michał Politowski Talking has been known to lead to communication if practised carelessly.
Re: Intel EM64T porting machine for Debian
On Sat, Dec 11, 2004 at 11:36:21AM +0100, Tollef Fog Heen wrote: > > In addition, we have at least two other machines which are available > to developers: > > pergolesi.debian.org -- admin is debian-admin (and all developers have > accounts already) Currently, this machine is *not* suitable for amd64 port development, since the 64bit chroots do not have glibc-dev installed. Short story: to have security support, the box run woody/i386. The box run a 2.4 kernel since woody does not work well with linux 2.6.x. On the other hand, the amd64 glibc package require a 2.6 kernel. So we are stuck until either 1) amd64 glibc package is safe to run with a 2.4 kernel or 2) sarge/i386 is supported by security team. Cheers, -- Bill. <[EMAIL PROTECTED]> Imagine a large red swirl here.
Bug#285207: ITP: kwirelessmonitor -- KWirelessMonitor is a small KDE application that docks into the system tray and monitors the wireless network interface
Package: wnpp Severity: wishlist * Package name: kwirelessmonitor Version : x.y.z Upstream Author : Name <[EMAIL PROTECTED]> * URL : http://www.example.org/ * License : (GPL, LGPL, BSD, MIT/X, etc.) Description : KWirelessMonitor is a small KDE application that docks into the system tray and monitors the wireless network interface KWirelessMonitor is a small KDE application that docks into the system tray and monitors the wireless network interface . The systray icon shows the signal quality and the bit rate using a "bar graph" and a "pie chart", respectively. In the configuration dialog, you can change the bit rate and power management settings of the wireless interface. It is also able to automatically enable power management when using battery power and/or automatically disable power management during data transfer. By default, KWirelessMonitor tries to automatically detect the wireless interface -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.9 Locale: LANG=C, LC_CTYPE=pl_PL (charmap=ISO-8859-2)
Re: Bug#285207: ITP: kwirelessmonitor -- KWirelessMonitor is a small KDE application that docks into the system tray and monitors the wireless network interface
El sÃb, 11-12-2004 a las 17:39 +0100, Marcin Orlowski escribiÃ: > Package: wnpp > Severity: wishlist > > * Package name: kwirelessmonitor > Version : x.y.z > Upstream Author : Name <[EMAIL PROTECTED]> > * URL : http://www.example.org/ > * License : (GPL, LGPL, BSD, MIT/X, etc.) Could you please fill in the template? -- Jose Carlos Garcia Sogo [EMAIL PROTECTED] signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
Re: Bug#285207: ITP: kwirelessmonitor -- KWirelessMonitor is a small KDE application that docks into the system tray and monitors the wireless network interface
Hello Marcin, * Marcin Orlowski <[EMAIL PROTECTED]> [2004-12-11 18:12]: > Package: wnpp > Severity: wishlist > > * Package name: kwirelessmonitor > Version : x.y.z > Upstream Author : Name <[EMAIL PROTECTED]> > * URL : http://www.example.org/ > * License : (GPL, LGPL, BSD, MIT/X, etc.) > Description : KWirelessMonitor is a small KDE application that docks > into the system tray and monitors the wireless network interface you have forgotten some notes. regards nico -- Nico Golde - [EMAIL PROTECTED] | GPG: 1024D/73647CFF [EMAIL PROTECTED] | http://www.ngolde.de VIM has two modes - the one in which it beeps and the one in which it doesn't
Re: menu-method for .desktop files?
> Perhaps a stupid question because I do not understand all this menu stuff: > Would this (together with Gnome 2.8) fix the user menus in Gnome??? > This would be reall great for Sarge release! No, this is about fixing the available session types in gdm and kdm. */ Christoffer Sawicki <[EMAIL PROTECTED]>
Re: Bug#282409: ITP: mozilla-firefox-locale-pt-br -- Firefox Localization Package to Brazilian Portuguese.
Hi! The es_ES translation is packaged in a separate package, because we uploaded it before the mozilla-firefox-locale-all was ready. The next version of mozilla-firefox-locale-all will also include es_ES translation. Regards, César El Martes 07 Diciembre 2004 14:57, Javier Fernández-Sanguino Peña escribió: > On Thu, Nov 25, 2004 at 07:28:39AM +0100, Christian Perrier wrote: > > > > Can you indeed give us here the list of mozilla-firefox-locale-xx > > > > packages your package currently generates? > > > > > > For the moment: > > (..) > > There is no es_ES. I believe there were mozilla-firefox-locale-es-es > packages at some point in the archive. Isn't the translation available > upstream? > > Regards > > Javier
Re: LCC and blobs
On Sat, Dec 11, 2004 at 03:49:48PM +0100, Marco d'Itri wrote: > On Dec 11, Brian Nelson <[EMAIL PROTECTED]> wrote: > > > If it made any sense at all for a mainboard's BIOS to loaded by the > > Linux kernel at boot time with a non-free firmware blob, the current > > consensus (on debian-legal anyway) seems to be that Debian would not > > support it. Period. The drivers for it would have to go in contrib. > I did not notice there was a consensus on this. You are the only person I've seen express views similar to mine on debian-legal. All other participants argue for non-free-firmware-using drivers going in contrib. Also, the current practice already is moving in this direction. For example, the ipw2100 driver is in contrib. It's totally fucking insane, but hey, we seem to be fighting an uphill battle against insanity. -- For every sprinkle I find, I shall kill you!
Re: LCC and blobs
On Sat, Dec 11, 2004 at 03:07:56PM +0100, Goswin von Brederlow wrote: > Brian Nelson <[EMAIL PROTECTED]> writes: > > As far as I'm concerned, distribution of the firmware is the > > manufacturer's realm. Whether the manufacturer distributes it on an > > EPROM on the device itself, or on a CD shipped with the device, or just > > provides it for download from a website, I don't care. That's their > > decision. Debian should not care one bit how the firmware is loaded on > > the device, and the method used should not dictate whether a driver is > > DFSG-compliant. > > It doesn't. What matters is if the firmware itself is distributable at > all and if it is DFSG-compliant. You aren't reading what I've written. Virtually 100% of firmware out there (included on the device or loaded externally) is non-free. By your reasoning, the entire kernel should be moved to contrib since no free hardware exists on which it can run. I'm not going to discuss this with you if you insist on spewing out typical debian-legal bullshit without actually thinking first. -- For every sprinkle I find, I shall kill you!
Re: LCC and blobs
Le samedi 11 décembre 2004 à 11:00 -0800, Brian Nelson a écrit : > You are the only person I've seen express views similar to mine on > debian-legal. All other participants argue for non-free-firmware-using > drivers going in contrib. Do they? > Also, the current practice already is moving in this direction. For > example, the ipw2100 driver is in contrib. For a single package that won't work without the binary blob, that's a good policy. But for a driver that's built within the kernel, this is fucking stupid. We already have several packages with some features that only work when some non-free stuff is installed (see e.g. xine). What's wrong with the kernel having *some* modules needing non-free blobs? They won't work out of the box, but that's not a reason to exclude them from the kernel. This is more work for the kernel maintainers, more work for the users, and no gain. In fact, all these drivers (including ipw2x00) should be built with our kernel, and the binary firmwares that we can ship should be included in the non-free section. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Re: Intel EM64T porting machine for Debian
In article <[EMAIL PROTECTED]>, Bill Allombert <[EMAIL PROTECTED]> wrote: >On Sat, Dec 11, 2004 at 11:36:21AM +0100, Tollef Fog Heen wrote: >> >> In addition, we have at least two other machines which are available >> to developers: >> >> pergolesi.debian.org -- admin is debian-admin (and all developers have >> accounts already) > >Currently, this machine is *not* suitable for amd64 port development, >since the 64bit chroots do not have glibc-dev installed. > >Short story: to have security support, the box run woody/i386. >The box run a 2.4 kernel since woody does not work well with linux 2.6.x
Pre-Depends on emacs21? Re: cedet-common: breaks other packages in batch mode
Bug #270388 regards the cedet-common package breaking emacs -batch. A proposed fix in the bug report is for cedet-common to Pre-Depend on emacs21 | emacsen instead of depending on it. An NMU based on this proposed fix has already been uploaded to the DELAYED queue by Henning Glawe without first discussing on debian-devel as required by policy. I'm therefore posting this message to get a reasonable set of eyeballs on this issue. For my part, I think a Pre-Depends here is crude and inappropriate, as other comments in the log suggest to me that this is a remediable bug in cedet-common's startup code; but I haven't dug into it far enough to say for sure. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: LCC and blobs
On Sat, Dec 11, 2004 at 08:11:31PM +0100, Josselin Mouette wrote: > Le samedi 11 d?cembre 2004 ? 11:00 -0800, Brian Nelson a ?crit : > > You are the only person I've seen express views similar to mine on > > debian-legal. All other participants argue for non-free-firmware-using > > drivers going in contrib. > > Do they? Judge for yourself: http://lists.debian.org/debian-legal/2004/10/msg00089.html (and others...) > > Also, the current practice already is moving in this direction. For > > example, the ipw2100 driver is in contrib. > > For a single package that won't work without the binary blob, that's a > good policy. It's a completely inconsistent and arbitrary policy. Virtually *all* device drivers in existance require a binary blob to work. It's up to the manufacturer to provide the binary blob to the user when they purchase the device. Some devices have the blob on the hardware itself; for others, the manufactures ship it on CD or make it downloadable from a website. Some manufactures allow us to distribute it; others don't. We should not care what they do. That's up to the manufacturer's and the users of their hardware to work out. > But for a driver that's built within the kernel, this is fucking > stupid. We already have several packages with some features that only > work when some non-free stuff is installed (see e.g. xine). What's > wrong with the kernel having *some* modules needing non-free blobs? > They won't work out of the box, but that's not a reason to exclude > them from the kernel. This is more work for the kernel maintainers, > more work for the users, and no gain. > > In fact, all these drivers (including ipw2x00) should be built with our > kernel, and the binary firmwares that we can ship should be included in > the non-free section. That would be an acceptable though not ideal solution to me. -- For every sprinkle I find, I shall kill you!
Re: Bug#284642: ITP: dpkg-reversion -- change the version of a DEB file
Adam Heath wrote: Well, the plan is to make the dpkg-deb interface more formalized. What I mean, is being able to use it in a filter, with plugging input and output. Ie, multiple input methods: .deb, .rpm, filesystem filter mode: standard tar output output mode: filesystem, .deb, .rpm Repacking and editting then become easy to do. Is there web page for such plans? I couldn't find anything useful with Google. Regards, ogi
Re: LCC and blobs
Brian Nelson <[EMAIL PROTECTED]> writes: > It's a completely inconsistent and arbitrary policy. It's hardly that. We distribute only free software, that's our rule. The rest, as you say, is for the manufacturer and the user to work out, but we disvalue non-free software, and so we don't distribute it in main. (And packages which require it go into contrib.) You only see it as inconsistent because you think the relevant consideration is "do we support this hardware", and you don't care how we support it. Most of us *do* care; we support it provided we can do so without distributing non-free software, because Debian is 100% Free Software. Things we cannot support with free software we do not support. This is not an inconsistent policy; this is the core of what Debian stands for. To say it is arbitrary is worse, because that insults the motives of the people who disagree with you. Thomas
Re: LCC and blobs
On Sat, Dec 11, 2004 at 11:50:44AM -0800, Thomas Bushnell BSG wrote: > Brian Nelson <[EMAIL PROTECTED]> writes: > > > It's a completely inconsistent and arbitrary policy. > > It's hardly that. We distribute only free software, that's our rule. > The rest, as you say, is for the manufacturer and the user to work > out, but we disvalue non-free software, and so we don't distribute it > in main. (And packages which require it go into contrib.) The device drivers in question *are* 100% free software! You say they should go into contrib because they depend on non-free software. However, *all* device drivers depend on non-free software. Why does it matter if that non-free stuff is stored on the device itself or is loaded externally? > You only see it as inconsistent because you think the relevant > consideration is "do we support this hardware", and you don't care how > we support it. I didn't say that. I'm saying we should distribute all free device drivers in main because they are free. Binary blobs are a non-issue. > Most of us *do* care; we support it provided we can do > so without distributing non-free software, because Debian is 100% Free > Software. Things we cannot support with free software we do not > support. This is not an inconsistent policy; this is the core of what > Debian stands for. All hardware depends on non-free software. If you want to lobby for all hardware to be free, including the firmware/BIOS/whatever, then fine. That's a noble war to wage and I'd support your efforts. However, requiring a policy like this at this time is completely insane because no hardware exists that meets this requirement. > To say it is arbitrary is worse, because that insults the motives of > the people who disagree with you. Your motives baffle me, and I can't say I feel any shame in insulting them. -- For every sprinkle I find, I shall kill you!
Re: LCC and blobs
Brian Nelson <[EMAIL PROTECTED]> writes: > You say they should go into contrib because they depend on non-free > software. However, *all* device drivers depend on non-free software. > Why does it matter if that non-free stuff is stored on the device itself > or is loaded externally? Because if it were stored on the device itself, and always packaged with the device, then there *still* wouldn't be a dependency, because all owners of the hardware would already have the firmware. By contrast, in this case, some owners of the hardware do *not* have the firmware, which would be the whole reason for putting it in contrib. Think of it this way. For the card with the built-in firmware, the driver does not depend on any additional packages or software distribution to work. By contrast, for the card with the separate firmware, the driver *does* depend on that additional package to work. > All hardware depends on non-free software. If you want to lobby for all > hardware to be free, including the firmware/BIOS/whatever, then fine. > That's a noble war to wage and I'd support your efforts. Really? Will you support it in the traditional free software way, by saying "no, we don't support that, it's not free and we can't"? I guess not. The issue isn't whether there is non-free software which is depended on in some extremely loose sense of depended. (All hardware depends on the non-free software which runs the power grid too, right?) The issue is whether that other software is the kind of software which *could* be distributed for free. Because the separate firmware could be distributed as free software but is not, and because that failure to distribute it as free software hurts all the users who could have benefited from its free distribution, the package which depends on it goes in contrib. For the built-in firmware, which cannot be changed anyway, the failure to distribute it as free software is not hurting the user; rather, the decision to make it fixed on the card is what hurts the user. We cannot fix all problems; we stand for the specific case of free software, so that's why we do this one rather than that one. > However, requiring a policy like this at this time is completely insane > because no hardware exists that meets this requirement. "Completely insane"? > > To say it is arbitrary is worse, because that insults the motives of > > the people who disagree with you. > > Your motives baffle me, and I can't say I feel any shame in insulting > them.ed Then please stop posting. Debian has enough people who feel like disagreement is grounds for calling someone "completely insane" and "arbitrary" on the wrong mailing list. Take it to debian-legal.
lintian warning about /usr/X11R6/lib
One of my packages, xfonts-kapl, installs fonts to usr/X11R6/lib/X11/fonts, as it should, according to policy 11.8.5. I get a lintian warning that nothing should install to /usr/X11R6/lib unless it uses imake, and that is just reflecting policy 11.8.7. Seems like those two section contradict each other; where should the fonts go? If they are already going to the proper place, am I getting the warning because I forgot something else, or is it a lintian bug? -- Neil Roeth
Re: LCC and blobs
Le samedi 11 décembre 2004 à 11:44 -0800, Brian Nelson a écrit : > > For a single package that won't work without the binary blob, that's a > > good policy. > > It's a completely inconsistent and arbitrary policy. > > Virtually *all* device drivers in existance require a binary blob to > work. It's up to the manufacturer to provide the binary blob to the > user when they purchase the device. Some devices have the blob on the > hardware itself; for others, the manufactures ship it on CD or make it > downloadable from a website. Some manufactures allow us to distribute > it; others don't. We should not care what they do. That's up to the > manufacturer's and the users of their hardware to work out. We shouldn't care about how the hardware actually works. The question is only about what we distribute. If we distribute a package that cannot do anything without a non-free part which cannot be in Debian, it should go in contrib. If we distribute a package that mostly works, but provides added functionality when some non-free stuff is installed (e.g. read realplayer or WMV9 files), it can go into main. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Re: LCC and blobs
Brian Nelson <[EMAIL PROTECTED]> writes: > On Sat, Dec 11, 2004 at 08:11:31PM +0100, Josselin Mouette wrote: >> Le samedi 11 d?cembre 2004 ? 11:00 -0800, Brian Nelson a ?crit : >> > You are the only person I've seen express views similar to mine on >> > debian-legal. All other participants argue for non-free-firmware-using >> > drivers going in contrib. >> >> Do they? > > Judge for yourself: > > http://lists.debian.org/debian-legal/2004/10/msg00089.html > > (and others...) > >> > Also, the current practice already is moving in this direction. For >> > example, the ipw2100 driver is in contrib. >> >> For a single package that won't work without the binary blob, that's a >> good policy. > > It's a completely inconsistent and arbitrary policy. The split between main and contrib can be made pretty simple and consistent: Does the package in question depend on something outside of main? The linux kernel certainly does not depend on any specific firmware and in fact most users can use it perfectly without any. Some users do have special hardware wich needs extra firmware blobs but that hardly constitutes as depends. | Debian Policy | 3.5 Dependencies | | Every package must specify the dependency information about other | packages that are required for the first to work correctly. I think firmware blobs fall nicely under suggests and there is nothing wrong for a package in main (e.g. kernel-image-*) to suggest a package in non-free (e.g. broadcom-tg3-firmware-update). | 7.2 Binary Dependencies - Depends, Recommends, Suggests, Enhances, | Pre-Depends | | Suggests |This is used to declare that one package may be more useful with |one or more others. Using this field tells the packaging system |and the user that the listed packages are related to this one and |can perhaps enhance its usefulness, but that installing this one |without them is perfectly reasonable. With drivers that load external firmware files this split is possible leaving the driver in main inside the kernel and the non DFSG free firmware in non-free. For modules that are not part of the kernel the same argument doesn't work. A driver that is only for hardware X which only works with firmware is not functional without it. It would depend on the firmware -> contrib (at a minimum). > Virtually *all* device drivers in existance require a binary blob to > work. It's up to the manufacturer to provide the binary blob to the No. I have no binary blob (from Debian) at all on any of my debian systems spaning several archs. There is a huge difference between the hardware having firmware and the driver including or loading one. Don't confuse that. For Debian it is all about distribution. The rest does not matter at all. Debian is not distributing the firmware that is in hardwares eproms. Everything the user has is a big black box that somehow works. What's inside it does not matter, only what Debian distributes. > user when they purchase the device. Some devices have the blob on the > hardware itself; for others, the manufactures ship it on CD or make it > downloadable from a website. Some manufactures allow us to distribute > it; others don't. We should not care what they do. That's up to the > manufacturer's and the users of their hardware to work out. We don't care what blobs do as long as they are not linked into GPL software (like the kernel). Only then they have to follow the GPL. Standalone blobs just have to follow DFSG if they want to be in main and some of the BSD licensed blobs can be once they stop linking into the kernel. Blame it on the viral nature of the GPL. Actually having DFSG blobs is preferable since they can be included in the initrd or on the first CD (since that is a glomeration of works and not a single object) and can be used in the Debian-Installer. >> But for a driver that's built within the kernel, this is fucking >> stupid. We already have several packages with some features that only >> work when some non-free stuff is installed (see e.g. xine). What's >> wrong with the kernel having *some* modules needing non-free blobs? >> They won't work out of the box, but that's not a reason to exclude >> them from the kernel. This is more work for the kernel maintainers, >> more work for the users, and no gain. >> >> In fact, all these drivers (including ipw2x00) should be built with our >> kernel, and the binary firmwares that we can ship should be included in >> the non-free section. > > That would be an acceptable though not ideal solution to me. That is what people are trying to do in cases where the firmware blob can't be in main. Some can and should be. > -- > For every sprinkle I find, I shall kill you! MfG Goswin
Re: LCC and blobs
Brian Nelson <[EMAIL PROTECTED]> writes: > On Sat, Dec 11, 2004 at 11:50:44AM -0800, Thomas Bushnell BSG wrote: >> Brian Nelson <[EMAIL PROTECTED]> writes: >> >> > It's a completely inconsistent and arbitrary policy. >> >> It's hardly that. We distribute only free software, that's our rule. >> The rest, as you say, is for the manufacturer and the user to work >> out, but we disvalue non-free software, and so we don't distribute it >> in main. (And packages which require it go into contrib.) > > The device drivers in question *are* 100% free software! > > You say they should go into contrib because they depend on non-free > software. However, *all* device drivers depend on non-free software. > Why does it matter if that non-free stuff is stored on the device itself > or is loaded externally? Because the former works after installing the deb without the user ever doing anything about firmware. How do you even know there is firmware? Maybe it is all hardcoded into the chip? Without taking the hardware apart you can't know. Call me ignorant but what I don't see does not exist describes perfectly how it should be treated. In the later case the user actively has to download the firmware from somewhere and add it to his system. The extra files taints his filesystems and makes it less free. For example you can't just make a live CD out of it anymore because the non-free firmware file makes it not DFSG free. >> You only see it as inconsistent because you think the relevant >> consideration is "do we support this hardware", and you don't care how >> we support it. > > I didn't say that. I'm saying we should distribute all free device > drivers in main because they are free. Binary blobs are a non-issue. 'because they are free'? That is the first probelmatic point. Are they free or not. Some people say drivers that don't work are not free. Personaly I don't see anything in the DFSG (and common free licenses) saying things have to work, quite the opposite. But you are right that as much as possible should be in main. Seperating out the firmware blobs from the drivers (making them gpl compliant again) aims excatly at that. >> Most of us *do* care; we support it provided we can do >> so without distributing non-free software, because Debian is 100% Free >> Software. Things we cannot support with free software we do not >> support. This is not an inconsistent policy; this is the core of what >> Debian stands for. > > All hardware depends on non-free software. If you want to lobby for all > hardware to be free, including the firmware/BIOS/whatever, then fine. > That's a noble war to wage and I'd support your efforts. > > However, requiring a policy like this at this time is completely insane > because no hardware exists that meets this requirement. Users don't have to install firmware/bios/whatever before linux runs in the normal case. That is the difference. >> To say it is arbitrary is worse, because that insults the motives of >> the people who disagree with you. > > Your motives baffle me, and I can't say I feel any shame in insulting > them. MfG Goswin
Re: LCC and blobs
Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote: > Because if it were stored on the device itself, and always packaged > with the device, then there *still* wouldn't be a dependency, because > all owners of the hardware would already have the firmware. In most cases, the owner of the device will already have the firmware. If the package had code to copy the firmware off the manufacturer's shipped CD, would you be happy for the driver to then be in main? > Think of it this way. For the card with the built-in firmware, the > driver does not depend on any additional packages or software > distribution to work. By contrast, for the card with the separate > firmware, the driver *does* depend on that additional package to work. The dependency still exists - it just isn't expressed within the terms of our package management system. I am entirely happy to describe this distinction as arbitrary. -- Matthew Garrett | [EMAIL PROTECTED]
Re: LCC and blobs
Brian Nelson <[EMAIL PROTECTED]> writes: > On Sat, Dec 11, 2004 at 03:07:56PM +0100, Goswin von Brederlow wrote: >> Brian Nelson <[EMAIL PROTECTED]> writes: >> > As far as I'm concerned, distribution of the firmware is the >> > manufacturer's realm. Whether the manufacturer distributes it on an >> > EPROM on the device itself, or on a CD shipped with the device, or just >> > provides it for download from a website, I don't care. That's their >> > decision. Debian should not care one bit how the firmware is loaded on >> > the device, and the method used should not dictate whether a driver is >> > DFSG-compliant. >> >> It doesn't. What matters is if the firmware itself is distributable at >> all and if it is DFSG-compliant. > > You aren't reading what I've written. Virtually 100% of firmware > out there (included on the device or loaded externally) is non-free. By > your reasoning, the entire kernel should be moved to contrib since no > free hardware exists on which it can run. Sure it runs on free hardware. On 100% free hardware. Take a pen, a paper and the boch source code and run your own linux on the pen+paper system. :) Ok, it's a bit insane, but possible. But let me say it again: "What matters is if the firmware itself is distributable at all and if it is DFSG-compliant." Your case of hardware wich already includes firmware is totaly irelevant since Debian does not distributes hardware, does not even stand for free hardware nor do debs have to depend on hardware. For all the main / contrib rules in Debian hardware just is. No depends, no reason to move something to main. Imagine if the linux kernel would start to depend on all the hardware it has drivers for. Would I have to buy a IPC Vortex raid card before dpkg lets me install the linux kernel? Insanity. > I'm not going to discuss this with you if you insist on spewing out > typical debian-legal bullshit without actually thinking first. Sorry for spewing out legal thinking but that is what it is mostly. Legal matters have no common sense. And may I remind you that you (being a DD) created this mess by voting for "Debian is 100% free". If Debian were just free Software thinks would look different. MfG Goswin
Re: amd64: ftp-masters questions
Martin Michlmayr - Debian Project Leader <[EMAIL PROTECTED]> writes: > * Goswin von Brederlow <[EMAIL PROTECTED]> [2004-12-11 15:17]: >> > Is there any progress on this issue? >> >> This seems to be one of your unfrozen mails (1. Aug, huh?). But it is >> still as valid as back then. > > My recollection is that all technical concerns were addressed and that > the port would go in after the mirror issues will be sorted out (which > will happen some point after sarge). > -- > Martin Michlmayr > [EMAIL PROTECTED] Fine. I will take this as official confirmation of what the debian-amd64 team had just suspected so far. Thanks Goswin
Re: LCC and blobs
Goswin von Brederlow writes: > Brian Nelson <[EMAIL PROTECTED]> writes: > > > You aren't reading what I've written. Virtually 100% of firmware > > out there (included on the device or loaded externally) is non-free. By > > your reasoning, the entire kernel should be moved to contrib since no > > free hardware exists on which it can run. > > Sure it runs on free hardware. On 100% free hardware. Take a pen, a > paper and the boch source code and run your own linux on the pen+paper > system. :) > > Ok, it's a bit insane, but possible. > > But let me say it again: "What matters is if the firmware itself is > distributable at all and if it is DFSG-compliant." You contradict yourself. You can execute the firmware-loading driver on pen and paper also; it operates just as well as the rest of the kernel does. Less trivially, imagine a device that speaks the same protocol as the "problematic" device+firmware combination -- with the distinction of not needing firmware. Since the software can use that device instead, the status of the firmware is irrelevant. Otherwise, we must move clients and servers for network protocols into contrib if the other end is not implemented by software in main: they do not function properly without the other end. Some examples would be things that speak AIM, MSN, Yahoo! messenger, etc. Since some suggest that Linux kernel modules should be moved to contrib while the rest of the kernel stays in main, it seems reasonable that AIM support for gaim, naim, etc. should also be moved to contrib. Michael Poole
Re: LCC and blobs
On Dec 11, Goswin von Brederlow <[EMAIL PROTECTED]> wrote: > Your case of hardware wich already includes firmware is totaly > irelevant since Debian does not distributes hardware, does not even > stand for free hardware nor do debs have to depend on hardware. And why it should be different if that firmware is distributed by the manufacturer on a CD instead of a flash EPROM chip? -- ciao, | Marco | [9711 deqGE2zroRuAE] signature.asc Description: Digital signature
Re: LCC and blobs
On Dec 11, Brian Nelson <[EMAIL PROTECTED]> wrote: > You are the only person I've seen express views similar to mine on > debian-legal. No, others did too, even if most of them did not bother arguing to death like I'm doing. > Also, the current practice already is moving in this direction. For > example, the ipw2100 driver is in contrib. I know many other drivers which are not, I see not "current practice". -- ciao, | Marco | [9712 trPH2vo/WPiO2] signature.asc Description: Digital signature
Re: LCC and blobs
On Dec 11, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote: > You only see it as inconsistent because you think the relevant > consideration is "do we support this hardware", and you don't care how > we support it. Most of us *do* care; we support it provided we can do > so without distributing non-free software, because Debian is 100% Free > Software. Things we cannot support with free software we do not > support. This is not an inconsistent policy; this is the core of what > Debian stands for. What are you talking about? We are not discussing distribution of non-free software, and the quantity of non-free software present on users' systems does not change whatever the outcome of this discussion. -- ciao, | Marco | [9714 avzOvc9E2tCDE] signature.asc Description: Digital signature
Re: LCC and blobs
Matthew Garrett <[EMAIL PROTECTED]> writes: > > Think of it this way. For the card with the built-in firmware, the > > driver does not depend on any additional packages or software > > distribution to work. By contrast, for the card with the separate > > firmware, the driver *does* depend on that additional package to work. > > The dependency still exists - it just isn't expressed within the terms > of our package management system. I am entirely happy to describe this > distinction as arbitrary. And yet, in this case the non-freeness of the software isn't hurting the user. The point isn't whether the firmware "exists", the point is whether the user is being prevented from modifying it by licensing or non-source-distribution restrictions.
Re: LCC and blobs
[EMAIL PROTECTED] (Marco d'Itri) writes: > On Dec 11, Goswin von Brederlow <[EMAIL PROTECTED]> wrote: > > > Your case of hardware wich already includes firmware is totaly > > irelevant since Debian does not distributes hardware, does not even > > stand for free hardware nor do debs have to depend on hardware. > And why it should be different if that firmware is distributed by the > manufacturer on a CD instead of a flash EPROM chip? Because in that case the manufacturer is hurting the user by not providing source, and we are against that. The case where the manufacturer hurts the user by hardwiring the program into an EPROM is also bad, but Debian is not here to work against that.
Re: LCC and blobs
[EMAIL PROTECTED] (Marco d'Itri) writes: > On Dec 11, Brian Nelson <[EMAIL PROTECTED]> wrote: > > > You are the only person I've seen express views similar to mine on > > debian-legal. > No, others did too, even if most of them did not bother arguing to death > like I'm doing. Please continue your argument on debian-legal. NOT HERE.
Re: LCC and blobs
Thomas Bushnell BSG writes: > Matthew Garrett <[EMAIL PROTECTED]> writes: > > > > Think of it this way. For the card with the built-in firmware, the > > > driver does not depend on any additional packages or software > > > distribution to work. By contrast, for the card with the separate > > > firmware, the driver *does* depend on that additional package to work. > > > > The dependency still exists - it just isn't expressed within the terms > > of our package management system. I am entirely happy to describe this > > distinction as arbitrary. > > And yet, in this case the non-freeness of the software isn't hurting > the user. The point isn't whether the firmware "exists", the point is > whether the user is being prevented from modifying it by licensing or > non-source-distribution restrictions. When the firmware is burned into the device, the user is prevented from modifying it in a rather more drastic and permanent fashion than when the restrictions are a matter of missing code or permissions. Michael Poole
Re: LCC and blobs
Le samedi 11 décembre 2004 à 13:45 -0800, Thomas Bushnell BSG a écrit : > Please continue your argument on debian-legal. NOT HERE. Why should this go on debian-legal? I think the legal status and DFSG-freeness of these firmwares is pretty clear. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Re: LCC and blobs
Michael Poole <[EMAIL PROTECTED]> writes: > When the firmware is burned into the device, the user is prevented > from modifying it in a rather more drastic and permanent fashion than > when the restrictions are a matter of missing code or permissions. Sure, but that's not the point. If someone prevents me from modifying a program by the use of licensing permissions or binary-only distribution, that's a Debian concern. If someone prevents me by the use of extortion or kidnapping, it's much worse, but not a Debian concern. We are pro-free software; we are neutral about the burning of software into devices. Thomas
Re: LCC and blobs
Josselin Mouette <[EMAIL PROTECTED]> writes: > Le samedi 11 dÃcembre 2004 Ã 13:45 -0800, Thomas Bushnell BSG a Ãcrit : > > Please continue your argument on debian-legal. NOT HERE. > > Why should this go on debian-legal? I think the legal status and > DFSG-freeness of these firmwares is pretty clear. Then it doesn't go anywhere. It certainly isn't for debian-devel.
Re: LCC and blobs
Le samedi 11 décembre 2004 à 13:51 -0800, Thomas Bushnell BSG a écrit : > > Why should this go on debian-legal? I think the legal status and > > DFSG-freeness of these firmwares is pretty clear. > > Then it doesn't go anywhere. It certainly isn't for debian-devel. Of course it is. This is about how to deal with this situation, technically speaking. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Re: LCC and blobs
(Please try to not Cc me on every reply. My messages even contain a Mail-Followup-To header.) On Dec 11, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote: > > And why it should be different if that firmware is distributed by the > > manufacturer on a CD instead of a flash EPROM chip? > > Because in that case the manufacturer is hurting the user by not > providing source, and we are against that. So this is just your personal opinion, not something required by the policy. Debian is pro and against many things, but I can't see a part of the policy which requires removing free software from the distribution to make a political point about software distributed by others. > The case where the manufacturer hurts the user by hardwiring the > program into an EPROM is also bad, but Debian is not here to work > against that. Why not? Your opinion again? This looks very arbitrary to me. -- ciao, | Marco | [9717 baWxxbS0wpbw6] signature.asc Description: Digital signature
Re: LCC and blobs
On Dec 11, Goswin von Brederlow <[EMAIL PROTECTED]> wrote: > > I know about no drivers which are useless without a non-free firmware, > > while I know about a huge number of hardware devices which are useless > > without a non-free firmware. > So the drivers without the firmware are usefull (i.e. make the > hardware work) but the hardware doesn't work without firmware > (i.e. make the driver fail)? > > You contradict yourself. No, I don't: the driver is the same with or without the firmware being uploaded to an external device, so if it does not physically change then its intrinsic usefulness cannot change. The driver does not "fail" if the hardware device is missing its firmware: it will merely report the device status, which is what it's designed to do. -- ciao, | Marco | [9718 noDpxhxiwNll.] signature.asc Description: Digital signature
Re: LCC and blobs
On Dec 11, Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
> > I do not believe that this is obvious. I understand that FSF disagrees,
> > and considers firmwares to be just "data".
>
> Would you accept a patch for ppp of the form:
>
> char data[] = { 0x17, 0x23, 0x42, ...};
> ...
> *(int (*)(int))data(fd);
>
> After all, it is just data.
No, because these bytes are executed on the system CPU under the control
of the OS, so to me they look like software.
> The FSF also things the GFDL is free, nothing new there. I also highly
> doubt even the FSF would consider a file stating "DO NOT DISTRIBUTE"
> as being GPL compatible because it is "just data". And some of the
> files in question in the kernel do.
I was not talking about this kind of files (which obviously have some
kind of licensing problem).
> > Not so small: the drivers for most WiFi network adapters, many bluetooth
> > adapters, all USB DSL modems, most (all?) DVB receivers, most 3D video
> > cards are just the ones I can think about right now.
> I don't know about WiFi or bluetooh but the usb dsl modems seem to
> work fine with e.g. eagle-usb-* packages.
You choose as an example a package which under the proposed
interpretation of policy would be removed from the distribution.
*ALL* drivers for USB modems are like this (I know: I have spent over
two months making Debian the distribution with the best support for them).
> And I haven't heart of any 3D video card that _requires_ extra
> firmware to work at all. It is true that you need extras to benefit
> from 3D but that doesn't make them non-functional. 2D support is good
It makes 3D non functional (I'm talking about Radeon and Matrox cards),
this looks like important enough for me.
> enough to install extra modules. It might be more work but there is no
> requirement for tainting the main kernel image with non-free 3D
> drivers.
We are not discussing distribution of non-free drivers, but 100% free
(GPL'ed or X11) drivers.
> PS: I was going by the list of troublesome files posted month ago,
> maybe that was incomplete but it wasn't overly long (comparted to
> kernel size).
It did not contain drivers which load firmwares from an external file.
That list is much longer, especially if you add drivers which are not in
the kernel tree.
--
ciao, |
Marco | [9715 buPH875bquuVQ]
signature.asc
Description: Digital signature
Re: LCC and blobs
Josselin Mouette <[EMAIL PROTECTED]> writes: > Le samedi 11 dÃcembre 2004 Ã 13:51 -0800, Thomas Bushnell BSG a Ãcrit : > > > Why should this go on debian-legal? I think the legal status and > > > DFSG-freeness of these firmwares is pretty clear. > > > > Then it doesn't go anywhere. It certainly isn't for debian-devel. > > Of course it is. This is about how to deal with this situation, > technically speaking. What is the technical question here? "Whether the package depends on non-free software?" "Whether an exception should be made for this case?" "Whether we should change our existing policies?" All are for debian-legal or debian-project.
Re: LCC and blobs
[EMAIL PROTECTED] (Marco d'Itri) writes: > (Please try to not Cc me on every reply. My messages even contain a > Mail-Followup-To header.) > > On Dec 11, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote: > > > > And why it should be different if that firmware is distributed by the > > > manufacturer on a CD instead of a flash EPROM chip? > > > > Because in that case the manufacturer is hurting the user by not > > providing source, and we are against that. > So this is just your personal opinion, not something required by the > policy. Debian is pro and against many things, but I can't see a part of > the policy which requires removing free software from the distribution > to make a political point about software distributed by others. Really? What do you think is the reason for separating contrib from main?
Re: LCC and blobs
Matthew Garrett <[EMAIL PROTECTED]> wrote: This would make more sense if I sent it to the right list, really. Sorry about that. > Brian Nelson <[EMAIL PROTECTED]> wrote: > >> You are the only person I've seen express views similar to mine on >> debian-legal. All other participants argue for non-free-firmware-using >> drivers going in contrib. > > (cough) > > I'm still entirely unclear on the logic of moving drivers that require > firmware to be loaded from disk to contrib. If they didn't require that > non-free code to be on disk, it'd be in a ROM on the device instead. All > drivers require non-free firmware - whether we have to ship it or not > should not affect the freedom (or otherwise) of a driver. > > Let's pretend that Debian actually has a significant amount of leverage > on this sort of issue, and that vendors see their drivers appearing in > contrib and want to do something about it. They /could/ open the > firmware and provide a toolchain for it. We'd put the driver in main, > then. Alternatively, they could put the firmware in ROM. In this case, > the amount of non-free code on a user's system would not change, but > we'd move the driver to main anyway. > > Note that this doesn't mean I think firmware should be in main. But I > think that's an entirely separate argument. Picking on drivers that > force us to notice their dependencies on non-free code while ignoring > drivers that are just as dependent (but in a less obvious way) is > hypocrisy. -- Matthew Garrett | [EMAIL PROTECTED]
Re: LCC and blobs
Goswin von Brederlow <[EMAIL PROTECTED]> wrote: > With drivers that load external firmware files this split is possible > leaving the driver in main inside the kernel and the non DFSG free > firmware in non-free. This argument suggests that we can shift drivers from contrib to main simply by turning them into kernel patches and getting them included in the stock kernel. This seems, uh, odd. > No. I have no binary blob (from Debian) at all on any of my debian > systems spaning several archs. There is a huge difference between the > hardware having firmware and the driver including or loading > one. Don't confuse that. But... > For Debian it is all about distribution. The rest does not matter at > all. Debian is not distributing the firmware that is in hardwares > eproms. Everything the user has is a big black box that somehow > works. What's inside it does not matter, only what Debian distributes. No. Debian is not about distribution. It is about free software. We don't make the distinction between main and contrib because of distribution requirements - we make it because we think that free code that requires non-free code is "tainted" by this. We put it in contrib so that people know that by using this software, they will also have to use non-free code. This is less obvious for drivers that use firmware in flash, but it's still true. For what it's worth, we don't distribute the ipw2100 firmware. The user has to obtain that themself. For various other bits of hardware, the firmware is already on a CD that the user owns. > We don't care what blobs do as long as they are not linked into GPL > software (like the kernel). Only then they have to follow the GPL. > Standalone blobs just have to follow DFSG if they want to be in main > and some of the BSD licensed blobs can be once they stop linking into > the kernel. Blame it on the viral nature of the GPL. Yes. That's an entirely separate issue. The definition of a DFSG blob is difficult, though. -- Matthew Garrett | [EMAIL PROTECTED]
Re: LCC and blobs
Matthew Garrett <[EMAIL PROTECTED]> writes: > Let's pretend that Debian actually has a significant amount of leverage > on this sort of issue, and that vendors see their drivers appearing in > contrib and want to do something about it. They /could/ open the > firmware and provide a toolchain for it. We'd put the driver in main, > then. Alternatively, they could put the firmware in ROM. In this case, > the amount of non-free code on a user's system would not change, but > we'd move the driver to main anyway. So they might do the right thing! And they choose a mechanism for inhibiting users other than licensing restrictions. Either way, it ceases to be Debian's game. We are for free software, and there are a lot of ways to hurt people that Debian is not concerned with. > Note that this doesn't mean I think firmware should be in main. But I > think that's an entirely separate argument. Picking on drivers that > force us to notice their dependencies on non-free code while ignoring > drivers that are just as dependent (but in a less obvious way) is > hypocrisy. No, because we have chosen a limited set of goals. We are for free software, not Curing All The World's Ills. There is nothing hypocritical about Debian deciding to attack one problem (non-free software) without attacking a different problem (unchangeable burned-in software).
Re: LCC and blobs
Matthew Garrett <[EMAIL PROTECTED]> writes: > This argument suggests that we can shift drivers from contrib to main > simply by turning them into kernel patches and getting them included in > the stock kernel. This seems, uh, odd. That's our policy. Every policy will have curious corner cases. ::shrug:: But if you want a new policy, it should be discussed on debian-project or perhaps debian-policy. Thomas
Re: LCC and blobs
On Dec 11, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote: > > All hardware depends on non-free software. If you want to lobby for all > > hardware to be free, including the firmware/BIOS/whatever, then fine. > > That's a noble war to wage and I'd support your efforts. > Really? Will you support it in the traditional free software way, by > saying "no, we don't support that, it's not free and we can't"? I > guess not. Is this what you are doing? Are you refusing to use modern computers because you do not have the source code for the many firmwares contained in their devices? I suppose not, so by following your reasoning I have to conclude that you support some non-free software. > The issue isn't whether there is non-free software which is depended > on in some extremely loose sense of depended. (All hardware depends > on the non-free software which runs the power grid too, right?) The > issue is whether that other software is the kind of software which > *could* be distributed for free. Do you know about some software which *could not* be distributed freely? Please explain. > Because the separate firmware could be distributed as free software > but is not, and because that failure to distribute it as free software > hurts all the users who could have benefited from its free > distribution, the package which depends on it goes in contrib. I cannot follow the last part of your reasoning, or at least I cannot reconduct it to policy. Again, I say "arbitrary". > For the built-in firmware, which cannot be changed anyway, the failure > to distribute it as free software is not hurting the user; rather, the > decision to make it fixed on the card is what hurts the user. Why do you think it cannot be changed? Many modern devices have it stored on a flash EEPROM chip. Apparently you are not well informed on the subject being discussed. And even if it where stored in ROM, so what? Many older computers came with the ROM source code printed on paper, and there is no technical reason which would forbid doing this for modern hardware too. Also, the decision of keeping a firmware on non-volatile storage is a *technical* one, not political: with most modern devices this is only useful if the hardware may be needed to perform the system bootstrap. -- ciao, | Marco | [9720 coUsIkzd32x5k] signature.asc Description: Digital signature
Re: LCC and blobs
Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote: > Matthew Garrett <[EMAIL PROTECTED]> writes: >> The dependency still exists - it just isn't expressed within the terms >> of our package management system. I am entirely happy to describe this >> distinction as arbitrary. > > And yet, in this case the non-freeness of the software isn't hurting > the user. The point isn't whether the firmware "exists", the point is > whether the user is being prevented from modifying it by licensing or > non-source-distribution restrictions. Oh, but it does. Having the source code to the firmware of my DVD drive would allow me to remove some silly restrictions. I've even got software that would allow me to reflash it. Now, you could make the argument that if I bought the DVD drive then I've never agreed not to reverse engineer the code in question. On the other hand, the documentation attempts to claim that I have no right to do so, and if I installed the Windows drivers they'd make me agree to do the same thing. If you've got any European case law that shows that I have significantly more rights because the software is in flash instead of on disk, I'd be fascinated to hear it. I've no especially good reason to believe that to be true at present. -- Matthew Garrett | [EMAIL PROTECTED]
Re: LCC and blobs
Michael Poole <[EMAIL PROTECTED]> wrote: > Thomas Bushnell BSG writes: >> And yet, in this case the non-freeness of the software isn't hurting >> the user. The point isn't whether the firmware "exists", the point is >> whether the user is being prevented from modifying it by licensing or >> non-source-distribution restrictions. > > When the firmware is burned into the device, the user is prevented > from modifying it in a rather more drastic and permanent fashion than > when the restrictions are a matter of missing code or permissions. Indeed. If I want to flash various bits of hardware I have, I need to reverse engineer the flash method first. This isn't necessary if I have a driver that uploads an image on every boot. If the firmware isn't in flash, I'm completely screwed. -- Matthew Garrett | [EMAIL PROTECTED]
Re: LCC and blobs
Matthew Garrett <[EMAIL PROTECTED]> writes: > Oh, but it does. Having the source code to the firmware of my DVD drive > would allow me to remove some silly restrictions. I've even got software > that would allow me to reflash it. Now, you could make the argument that > if I bought the DVD drive then I've never agreed not to reverse engineer > the code in question. On the other hand, the documentation attempts to > claim that I have no right to do so, and if I installed the Windows > drivers they'd make me agree to do the same thing. Yes, I was speaking earlier not of this sort, but of the unchangeable built-in kind of firmware. But the question still is: who is distributing it? We have a simple bright-line test, easy to apply fairly; if you want a new test, then please make the proposal in the proper place.
Re: LCC and blobs
Le samedi 11 décembre 2004 à 21:47 +, Matthew Garrett a écrit : > Goswin von Brederlow <[EMAIL PROTECTED]> wrote: > > > With drivers that load external firmware files this split is possible > > leaving the driver in main inside the kernel and the non DFSG free > > firmware in non-free. > > This argument suggests that we can shift drivers from contrib to main > simply by turning them into kernel patches and getting them included in > the stock kernel. This seems, uh, odd. Odd, but that's how it should be. > We put it in contrib > so that people know that by using this software, they will also have to > use non-free code. This is less obvious for drivers that use firmware in > flash, but it's still true. Where do you put xine, then? It works fine with only free code, but can open more formats when dlopen()ing optional non-free libraries. Should it go outside of main because it is "tainted"? I don't believe so; the user himself chooses to taint his system by installing these libraries. The problem is exactly the same for non-free blobs: the user will know he is installing some non-free stuff, either by downloading it from our non-free archive, either by installing it by himself. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Re: Bug#284642: ITP: dpkg-reversion -- change the version of a DEB file
On Sat, 2004-12-11 at 21:51 +0200, Ognyan Kulev wrote: > Adam Heath wrote: > > Well, the plan is to make the dpkg-deb interface more formalized. What I > > mean, is being able to use it in a filter, with plugging input and output. > > > > Ie, multiple input methods: .deb, .rpm, filesystem > > > > filter mode: standard tar output > > > > output mode: filesystem, .deb, .rpm > > > > Repacking and editting then become easy to do. > > Is there web page for such plans? I couldn't find anything useful with > Google. > I certainly don't share these plans. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Re: LCC and blobs
Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote: > No, because we have chosen a limited set of goals. We are for free > software, not Curing All The World's Ills. There is nothing > hypocritical about Debian deciding to attack one problem (non-free > software) without attacking a different problem (unchangeable > burned-in software). Burned-in software is, in general, non-free software. It would be as easy for us to write a free alternative as it would be to write a free version of firmware loaded from disk. Why do you believe this goal to be less important? -- Matthew Garrett | [EMAIL PROTECTED]
Bug#285234: ITP: unlzx -- unarchiver for *.lzx archives
Package: wnpp Severity: wishlist * Package name: unlzx Version : x.y.z Upstream Author : Name <[EMAIL PROTECTED]> * URL : http://ftp.uni-paderborn.de/aminetbin/find?unlzx * License : (GPL, LGPL, BSD, MIT/X, etc.) Description : unarchiver for *.lzx archives unlzx is (surprise!) LZX archive unpacking utility released under GNU license LZX archiver was most popular on Amiga platform some time ago and the archiver itself was formerly commercial and then released free of charge (but still closed-source). -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.9 Locale: LANG=C, LC_CTYPE=pl_PL (charmap=ISO-8859-2)
Bug#285233: ITP: undms -- unpacks DMS (Disk MaSher) floppy image archives
Package: wnpp Severity: wishlist * Package name: undms Version : x.y.z Upstream Author : [EMAIL PROTECTED] (David Tritscher) * URL : http://ftp.uni-paderborn.de/aminetbin/find?undms * License : (GPL, LGPL, BSD, MIT/X, etc.) Description : unpacks DMS (Disk MaSher) floppy image archives DMS is popular floppy disk image archiver. It reads floppy disk content, cruch'em down and writes DMS file as output. DMS archive is common way of distribution of amiga software whenever it needs to be stored on floppy, but can't be packed using regular file archives as LhA or LZx (it usually meeans demos and games). -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.9 Locale: LANG=C, LC_CTYPE=pl_PL (charmap=ISO-8859-2)
Re: LCC and blobs
Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote: > Matthew Garrett <[EMAIL PROTECTED]> writes: > >> This argument suggests that we can shift drivers from contrib to main >> simply by turning them into kernel patches and getting them included in >> the stock kernel. This seems, uh, odd. > > That's our policy. Every policy will have curious corner cases. >::shrug:: It also means that I can upload a kernel image that contains all these drivers, ensure that it's ABI compatible with the "official" kernels, and then build udebs containing the firmware-requiring drivers. These could then be grabbed by d-i. The drivers would then be available during install. So, for the cost of a relatively small amount of time, I could happily ensure that all these drivers end up in main. This suggests that there's something slightly wrong. The dependency on non-free code wouldn't have changed in the slightest. > But if you want a new policy, it should be discussed on debian-project > or perhaps debian-policy. I'm entirely happy to bring this up on debian-project. -- Matthew Garrett | [EMAIL PROTECTED]
Re: Bug#285234: ITP: unlzx -- unarchiver for *.lzx archives
On Sat, Dec 11, 2004 at 10:53:10PM +0100, Marcin Orlowski wrote: > Package: wnpp > Severity: wishlist > > * Package name: unlzx > Version : x.y.z > Upstream Author : Name <[EMAIL PROTECTED]> > * URL : http://ftp.uni-paderborn.de/aminetbin/find?unlzx > * License : (GPL, LGPL, BSD, MIT/X, etc.) > Description : unarchiver for *.lzx archives How can so many people fail to fill in all of the fields in reportbug's ITP template? Is there some way to make it more clear, or are people just lazy? -- gram
Re: LCC and blobs
Goswin von Brederlow <[EMAIL PROTECTED]> writes: > Brian Nelson <[EMAIL PROTECTED]> writes: > >> On Sat, Dec 11, 2004 at 03:07:56PM +0100, Goswin von Brederlow wrote: >>> Brian Nelson <[EMAIL PROTECTED]> writes: >>> > As far as I'm concerned, distribution of the firmware is the >>> > manufacturer's realm. Whether the manufacturer distributes it on an >>> > EPROM on the device itself, or on a CD shipped with the device, or just >>> > provides it for download from a website, I don't care. That's their >>> > decision. Debian should not care one bit how the firmware is loaded on >>> > the device, and the method used should not dictate whether a driver is >>> > DFSG-compliant. >>> >>> It doesn't. What matters is if the firmware itself is distributable at >>> all and if it is DFSG-compliant. >> >> You aren't reading what I've written. Virtually 100% of firmware >> out there (included on the device or loaded externally) is non-free. By >> your reasoning, the entire kernel should be moved to contrib since no >> free hardware exists on which it can run. > > Sure it runs on free hardware. On 100% free hardware. Take a pen, a > paper and the boch source code and run your own linux on the pen+paper > system. :) > > Ok, it's a bit insane, but possible. While you have your pen and paper out, go ahead and write some hardware that a contrib device driver can use without needing firmware loadable by the kernel. Put the firmware on the device itself. That contrib driver is now completely suitable for main by your definition. There is no direct relationship between a device driver and a binary firmware blob. The driver simply drives a device. It does not and should not care how a device gets the firmware loaded. That the currently available hardware requires firmware loaded by the kernel is a hardware implementation detail. If you don't like it, complain to the hardware manufacturer, or buy your hardware from somewhere else. Hardware is not Debian's realm. -- For every sprinkle I find, I shall kill you!
Re: LCC and blobs
Josselin Mouette <[EMAIL PROTECTED]> wrote: > Le samedi 11 d=E9cembre 2004 =E0 21:47 +, Matthew Garrett a =E9crit : >> We put it in contrib >> so that people know that by using this software, they will also have to >> use non-free code. This is less obvious for drivers that use firmware in >> flash, but it's still true. > > Where do you put xine, then? It works fine with only free code, but can > open more formats when dlopen()ing optional non-free libraries. Should > it go outside of main because it is "tainted"? I don't believe so; the > user himself chooses to taint his system by installing these libraries. > The problem is exactly the same for non-free blobs: the user will know > he is installing some non-free stuff, either by downloading it from our > non-free archive, either by installing it by himself. xine should certainly remain within main - it's useful without any non-free software. But then compare to, say, kernel-patch-2.6-bluez - all the devices that this code will work with have non-free firmware, though only one of them requires it to be loaded from userspace. Main or contrib? -- Matthew Garrett | [EMAIL PROTECTED]
Re: LCC and blobs
Matthew Garrett <[EMAIL PROTECTED]> writes: > Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote: > > > No, because we have chosen a limited set of goals. We are for free > > software, not Curing All The World's Ills. There is nothing > > hypocritical about Debian deciding to attack one problem (non-free > > software) without attacking a different problem (unchangeable > > burned-in software). > > Burned-in software is, in general, non-free software. It would be as > easy for us to write a free alternative as it would be to write a free > version of firmware loaded from disk. Why do you believe this goal to be > less important? It is important; go to it. I have not said you should not do it.
Re: LCC and blobs
Matthew Garrett <[EMAIL PROTECTED]> writes: > It also means that I can upload a kernel image that contains all these > drivers, ensure that it's ABI compatible with the "official" kernels, > and then build udebs containing the firmware-requiring drivers. These > could then be grabbed by d-i. The drivers would then be available during > install. Yes.
Re: LCC and blobs
Josselin Mouette <[EMAIL PROTECTED]> writes: > Le samedi 11 décembre 2004 à 11:44 -0800, Brian Nelson a écrit : >> > For a single package that won't work without the binary blob, that's a >> > good policy. >> >> It's a completely inconsistent and arbitrary policy. >> >> Virtually *all* device drivers in existance require a binary blob to >> work. It's up to the manufacturer to provide the binary blob to the >> user when they purchase the device. Some devices have the blob on the >> hardware itself; for others, the manufactures ship it on CD or make it >> downloadable from a website. Some manufactures allow us to distribute >> it; others don't. We should not care what they do. That's up to the >> manufacturer's and the users of their hardware to work out. > > We shouldn't care about how the hardware actually works. The question is > only about what we distribute. If we distribute a package that cannot do > anything without a non-free part which cannot be in Debian, it should go > in contrib. If we distribute a package that mostly works, but provides > added functionality when some non-free stuff is installed (e.g. read > realplayer or WMV9 files), it can go into main. > -- > .''`. Josselin Mouette/\./\ > : :' : [EMAIL PROTECTED] > `. `'[EMAIL PROTECTED] > `- Debian GNU/Linux -- The power of freedom Exactly, thanks. MfG Goswin
Re: Bug#285233: ITP: undms -- unpacks DMS (Disk MaSher) floppy image archives
On Sat, 11 Dec 2004 22:44:54 +0100, Marcin Orlowski wrote: > Package: wnpp > Severity: wishlist > > * Package name: undms > Version : x.y.z > Upstream Author : [EMAIL PROTECTED] (David Tritscher) > * URL : http://ftp.uni-paderborn.de/aminetbin/find?undms > * License : (GPL, LGPL, BSD, MIT/X, etc.) Is it really distributed under all these licenses (and others)? Rhetorical question. You just didn't care to specify one. The problem is, apparently the upstream author didn't either. > Description : unpacks DMS (Disk MaSher) floppy image archives -- Michał Politowski Talking has been known to lead to communication if practised carelessly.
Re: Bug#285234: ITP: unlzx -- unarchiver for *.lzx archives
On Sat, Dec 11, 2004 at 04:37:01PM -0600, Graham Wilson wrote: > On Sat, Dec 11, 2004 at 10:53:10PM +0100, Marcin Orlowski wrote: > > Package: wnpp > > Severity: wishlist > > > > * Package name: unlzx > > Version : x.y.z > > Upstream Author : Name <[EMAIL PROTECTED]> > > * URL : http://ftp.uni-paderborn.de/aminetbin/find?unlzx > > * License : (GPL, LGPL, BSD, MIT/X, etc.) > > Description : unarchiver for *.lzx archives > > How can so many people fail to fill in all of the fields in reportbug's > ITP template? Is there some way to make it more clear, or are people > just lazy? Maybe patching reportbug to complain if an ITP doesn't have some of its fields changed from the defaults would be a good idea? Steve --
Re: LCC and blobs
On Sat, Dec 11, 2004 at 02:23:16PM -0800, Brian Nelson wrote: > While you have your pen and paper out, go ahead and write some hardware > that a contrib device driver can use without needing firmware loadable > by the kernel. Put the firmware on the device itself. That contrib > driver is now completely suitable for main by your definition. > > There is no direct relationship between a device driver and a binary > firmware blob. The driver simply drives a device. It does not and > should not care how a device gets the firmware loaded. If the driver has to be able to open the file and read the blob so it can send it to the device, there's a clear relationship and dependency between the driver and the blob: if you don't have a copy of the blob, the driver doesn't work. (Spewing out "hardware error, firmware not loaded" doesn't count to me as "working".) The difference is simple: if running a device requires that a driver have access to a piece of data, the user must have access to that data (and so its copyright restrictions kick in; I might not be allowed to give it to you, even if the company that made the device no longer exists). If the device merely stores that software on the device itself, that isn't the case. If the user must be subjected to non-free restrictions to use a piece of software (such as a driver), it belongs in contrib; that's what contrib was created for. (The fact that this is a result of hardware implementation decisions is irrelevant.) -- Glenn Maynard
