Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
Sven Luther [EMAIL PROTECTED] writes: If even yourself are not able to understand it, and thus gives bogus advice, i guess you will find nobody. Sven Luther Maybe the reason the now proper advice wasn't given to you was that the feature did not exist back when you asked? Or you asked the question in a way that didn't trigger the right answere. I highly doubt understanding of the kernel-wedge was at fault here. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On Tue, Aug 15, 2006 at 10:03:08AM +0200, Goswin von Brederlow wrote: Sven Luther [EMAIL PROTECTED] writes: If even yourself are not able to understand it, and thus gives bogus advice, i guess you will find nobody. Sven Luther Maybe the reason the now proper advice wasn't given to you was that the feature did not exist back when you asked? Maybe, but then he should have said something such, and not started bashing on me. Or you asked the question in a way that didn't trigger the right answere. I was given the advice to do it as i did, and now he comes critizing me. I highly doubt understanding of the kernel-wedge was at fault here. The only thing at hand here, is indulging on another round of sven-bashing. It is purely non-constructive, since he has me in his killfill anyway even. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
Sven Luther [EMAIL PROTECTED] writes: On Sun, Aug 13, 2006 at 07:14:02PM +0200, Goswin von Brederlow wrote: Moving the problem from A to B. Doesn't matter what svn repository it is in. Yes, it does matter. If it is inside kernel-wedge, you need to upload kernel wedge to benefit from any fix, while if it is in d-i, you can just build the out-of-svn tree and be happy. And I can just as easily build the kernel-wedge out-of-svn. That really makes no difference. Furthermore, the build, failure, check what the heck kernel module has changed name or dissapeared, or whatnot, is a *ROYAL PAIN*, and very much time consuming., especially on slow arches with lot of flavours. A factor of 1 or so faster than building the linux-2.6 source. As combined time the kernel-wedge time is neglible. Ah, but the beauty of my proposal is that you have tool which handles the config files and module-as-udebs without needing to do a full build. Like Bastian created the nice debian/rules target to check all config options. Which helps exactly 0 if you build all the kernels and then detect that a module was not manualy maintained in the to be udeb-ed list. Since not all modules are to be put in udebs I see no way how you will automate the list. And instead of having a 1 minute run of kernel-wedge to build the udeb for the one generic kernel of most archs you have a 6h build of all the (non D-I except for generic) flavours. Getting a module into an udeb would be a hell of a lot more time consuming. Furthermore, given that you need to install the kernel image package, you can't even start to autobuild that without hosing the autobuilders. Last I use kernel-wedge, and this is ~2 years ago now, you could build all kernel udebs on a single arch with the help of a little wrapper script. Did somone break that? This has been rumored, but i have not seen this script, and the latest round of discussion during debconf/mexico, Frans rejected the idea of doing a single kernel .udeb package for all arches, claiming this was not possible, that it would break autobuilders who wanted to install the kernels and so on. But then, maybe he was isssuing clueless suppositions ? The script was in the repository and was never for auto-building. Buildds must install the kernel image package because a Build-Depends is the only way to download a deb on a buildd. You can not rely on a network connection during build so you can't download the debs some other way. And since you can't install a s390 kernel on arm that makes building for all archs impossible for buildds. With a manual build you can just apt-get the debs and unpack them on the spot without having to install anything. Rewrite that script. Get ride of it and build the .udebs from the kernel packages :) modules which need to go into each ramdisk flavour, not mentioning that the Which is pretty constant from my experience since the modules are already split right into udebs. They are split into the right .udebs for the x86 and other mainstream cases the kernel-wedge maintainer cares about. Even if they are not split right you don't change what udebs go into the ramdisk. You fix the split itself (which you already have to do, that work is already accounted for). So this part of the job is a NOP. Ah, but the interesting part of it comes when the constraint for x86 floppies and powerpc floppies for example impose different distribution of modules. That is why each arch has possibly different modules listed. And as Joeyh posted even per flavour. This is really a non problem solve years ago. As an example, i was not able to build apus flavoured .udebs, since i don't remember which .udeb included a module not built on apus, and which needed kernel-wedge modifications, which Frans forbade me to make. You were forbidden to do it. It wasn't impossible or even difficult. ramdisk package list has no support for per-flavour module selection, and you have to end up with stuff like the netboot64 list, which has as sole usage to add the ibm power hypervisor and virtualization modules, all an ugly mess. Something to improve. No argument for or against your proposal. Because you miss that my proposal makes this whole issue obsolet and non-existent. No it doesn't. You still have to list the modules that get into the ramdisk. That list doesn't magically build itself just because you parse .config. Again, you fail to understand. In the current case, you do the work 3 times : 1) the kernel team choses the configuration option for the kernel, and thus chose which modules to enable or not. Which is a trivial step as they basicaly enable all modules and hardly ever disable one again. 2) the kernel-wedge contains a list of modules per .udeb, and is completed by the linux-*-di packages, all 12+ of them. And per flavour. That list changes on kernel updates (not so often) and much more
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On Sun, Aug 13, 2006 at 02:26:20PM -0400, Joey Hess wrote: Goswin von Brederlow wrote: ramdisk package list has no support for per-flavour module selection, and you have to end up with stuff like the netboot64 list, which has as sole usage to add the ibm power hypervisor and virtualization modules, all an ugly mess. Something to improve. No argument for or against your proposal. I thought I'd respond to this, not because it's the first case of Sven posting incorrect information to this thread, but because it's one of the more egrarious. Quoting debian-installer/build/README: * 'pkg-lists' has subdirectories for the different image types that list udebs that are put on each image. The pkg-lists/*/common files list udebs common to all architectures, and the files named by architecture (arch.cfg) list udebs specific to an architecture. It is also possible to include udebs only on a specific subarchitecture by creating a directory for the architecture and putting config files for the subarchitecture there (arch/subarch.cfg). If you take a look at pkg-lists/netboot, you'll find things like: [EMAIL PROTECTED]:~/src/d-i/installer/build/pkg-lists/netboot/arml ads.cfg netwinder.cfg nslu2.cfg [EMAIL PROTECTED]:~/src/d-i/installer/build/pkg-lists/netboot/sparcl combined.cfg sparc32.cfg sparc64.cfg [EMAIL PROTECTED]:~/src/d-i/installer/build/pkg-lists/netboot/mipsell bcm947xx.cfg cobalt.cfg r3k-kn02.cfg r4k-kn04.cfg sb1-bcm91250a.cfg In fact, powerpc is the only architecture to use unnecessary hacks like netboot64, cdrom64, and netboot-apus. Ah, if i remember well, it was you (or Colin maybe ?), who suggested me the netboot64 and cdrom64 as the only solution for that problem. I think since then that the virtualization modules could be added to the normal netboot/cdrom powerpc flavours, with the ? optional flag. This was not existent when those flavours first got created though. I was going to do that, but as you kicked me out of the d-i team ... I'd be very happy if someone who cares about powerpc subarches and can read and understand documentation like the above could clean this up (if such a person exists). If even yourself are not able to understand it, and thus gives bogus advice, i guess you will find nobody. Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
maximilian attems [EMAIL PROTECTED] writes: On Sat, Aug 12, 2006 at 09:53:48PM -0700, Thomas Bushnell BSG wrote: Goswin von Brederlow [EMAIL PROTECTED] writes: Is it an aggregation with the image linked into the binary? It doesn't matter for Debian's purposes. While the GPL permits shipping a GPL'd program merely aggregated alongside a non-free program, we don't ship the nonfree part no matter what, so it hardly matters to us whether it's also a GPL violation. Thomas stop abusing debian-kernel, this thread is pointless. either you contribute as already pointed out by Md and fs or you may want start whining at other places. It was complained that valid bugs of the sort there is non-free software here and here and here were being closed summarily. Was this accurate? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On Sun, Aug 13, 2006 at 03:47:13AM +0200, Goswin von Brederlow wrote: The whole concept is of an extreme fragility, prone to break again and again, cause lot of work for all involved, who become irritable, and bash on you when you even mention it. I did it when working on the amd64 D-I for sarge. I found it quite trivial to do, a matter of minutes. In fact a hell of a lot simpler and way faster than getting the linux-2.6 source package to do something for me. Naturally, amd64 being one of the mainstream arches the d-i team cares about. Now, please provide patches for resurecting the apus flavour, and then we can speak again. The kernel-wedge lists do break from time to time but they are simple to adjust and quick to rebuild. And another advantage with kernel-wedge: You can easily take your (maybe even prebuild) custom kernel and create udebs from it. I would hate to have to add the SuSe or RH patch sets to the linux-2.6 source to build kernel udebs for hardware that requires their patches. This could be easily be solved by adding the module info to the source package in some way, or even integrate them into kernel-package. This, in my book, is not an example of good software engineering, and any proposal to help improve this should be worth considering. Still not convinced. You do have some points but I see more drawbacks and problems than advantages. At least you had the honestity to discuss it, while other rejected it out of hand, with patronizing and aggresive language. Is the space taken up by the installed modules your actual argument for having finer grained module udebs? Nope, but then i told you that in the first mail already :) Then you have presented no argument for splitting the module udebs and several against. Several ? You do have raised some points of improvement for kernel-wedge. Like automaticaly adjusting to changed .config files or some other magics you mentioned. And some points for building module udebs from within linux-2.6 source although I don't agree with you there. Why not ? It is the only way we can bring down the delay for security builds with abi change to the minimum time, and the less human intervention. The d-i team only needs to handle a list of the modules it want to include in this or that ramdisk, and all will work automatically. Which has the same problem as the kernel-wedge configuration has now when splitting the modules. When a module gets added or removed the list has to be adjusted. Err, no, because the list would be handled in the debian-installer package or its devel tree in the svn repo, and not inside kernel-wedge. Notice that we already have the mapping of module .udeb packages to d-i images in d-i proper, which needs to be done anyway in addition to the kernel-wedge/linux-xxx-di work. Furthermore with the current situation, and given that not all modules are built the same on all arches, and that binary size vary per arch, you end up in an unholy mess when trying to build space constrained ramdisks, like the floppy ones for example. Compared to the current situation, where the kernel porters have to update the config files, then build the kernel .deb, they have to pass NEW, then the d-i Still has to happen. Indeed, but that is the only part that needs to be done, not the rest. porters update the the kernel .udeb packages (one per arch), and the list of Which is mostly just a new upload. WRONG. it is at best an upload *PER ARCH*, done by *ONE DIFFERENT PERSON AT A DIFFERENT TIME* for each arch. Furthermore, the build, failure, check what the heck kernel module has changed name or dissapeared, or whatnot, is a *ROYAL PAIN*, and very much time consuming., especially on slow arches with lot of flavours. Furthermore, given that you need to install the kernel image package, you can't even start to autobuild that without hosing the autobuilders. modules which need to go into each ramdisk flavour, not mentioning that the Which is pretty constant from my experience since the modules are already split right into udebs. They are split into the right .udebs for the x86 and other mainstream cases the kernel-wedge maintainer cares about. ramdisk package list has no support for per-flavour module selection, and you have to end up with stuff like the netboot64 list, which has as sole usage to add the ibm power hypervisor and virtualization modules, all an ugly mess. Something to improve. No argument for or against your proposal. Because you miss that my proposal makes this whole issue obsolet and non-existent. So, the new proposal would mean the porters decide which config options (and thus which modules), should be built, as well, in conjunction with the d-i folk, which of those modules may be usefull for d-i, disks, networks, input devices, display devices, the decision is pretty easy. The d-i team only needs to handle a single list
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On Sat, Aug 12, 2006 at 09:53:48PM -0700, Thomas Bushnell BSG wrote: Goswin von Brederlow [EMAIL PROTECTED] writes: Is it an aggregation with the image linked into the binary? It doesn't matter for Debian's purposes. While the GPL permits shipping a GPL'd program merely aggregated alongside a non-free program, we don't ship the nonfree part no matter what, so it hardly matters to us whether it's also a GPL violation. Thomas stop abusing debian-kernel, this thread is pointless. either you contribute as already pointed out by Md and fs or you may want start whining at other places. -- maks ps stripped debian-release ml from cc: i'm not a d-release regular, but i fail to see any posted relevance. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On Sun, 13 Aug 2006 10:39:18 +0200 maximilian attems wrote: stop abusing debian-kernel, this thread is pointless. I disagree. Thanks especially to Goswin and Sven for your honest attempt at reaching a common understanding in these matters. It is certainly relevant, and although all the arguments in this thread may already be raised before, they were scattered across time and lists and (even more than here) cluttered with whining. Kind regards, - Jonas -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ - Enden er nær: http://www.shibumi.org/eoti.htm pgp1EtEIbyYY7.pgp Description: PGP signature
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On Sun, Aug 13, 2006 at 04:01:12AM +0200, Goswin von Brederlow wrote: Sven Luther [EMAIL PROTECTED] writes: On Sat, Aug 12, 2006 at 11:03:29PM +0200, Goswin von Brederlow wrote: Compare it to including a hexdump of an image or sound in a header file and including that in the binary. And compare it with having that same image or sound as external file shipped in the same deb. Well, the FSF argues that it is not important where the file is, as long as there is a logical link, in order to have the GPL cross the dynamic linking barrier. In the same way, the only relationship of the non-free firmware or your image or sound, is that it is transported in the same binary, and used as data offloaded to the peripheral device. Assume the image/sound was rendered/generated from some source format not included in the source. E.g. povray input. So ? What has this to do with it ? So you can't claim the hexdump (or binary file) is the prefered form of modification (source). Well, i never argued that, i always said that the binary-only firmwares without source, are non-DFSG-free, and should be handled accordyingly. The point is that they are not considered a derivative work of the kernel source, and thus that the presence of non-free firmware inside the kernel binary is no breakage of the kernel GPL. Is it an aggregation with the image linked into the binary? It depends if your binary is an image compressor, and only transports the image, or if said image is used in the binary for icons of its GUI for example or as splash screen. If I just dump my hexcode of the image/sound to my black box (qiv or xmms for example) for (dis)playing then I only transport the file. If I (dis)play it myself then it isn't an aggregation. Intresting. If the image is integral part of your program, it being non-free breaks the GPL of your program, independently of it being included in the same binary or not. displaying some random image doesn't count as 'being integral part of the program'. Or does the black box have to be hardware? nope, the same applies in all case, but i wish you would not mix the problems and provide false argumentation for the case we agree with, in order to disproof a totally different issue. aggregated code from the kernel image? Not relevant. If it is an aggregation then there must be a way to break it up and only keep the GPLed parts. I think that is very much relevant. I don't think you can call something an aggregation if it is inseperably bound together. Well, sure there is part to separate them. You could imagine a (non-free) tool called before lilo or grub, and which would upload those firmwares for the peripheral device to be ready when the free driver comes into play. I can imagine a tool that rewrites non-free parts of a binary as free software from scratch without breaking any laws about reverse engeneering too. Does that mean they exist or are even possible? no. Well, what is a bios apart from a tool which runs at system startup and initialises the peripheral procesors in a state which will allow later programs to use it ? I do bios/firmware writing for a living, and plan to embedd exactly such non-free firmware into the flash firmware of my board, to power onboard devices that need them. So, again, what was your argumentation here ? Or you could use the new initramfs/firmware loading kernel infrastructure to separate the firmware from the kernel. That requires changes in the source. Exactly those changes is what I say must happen. Indeed. and i *NEVER* said that they should not happen, i *NEVER said that this was the point we are discussing, i actually *AGREE* with you there. This is a fully orthogonal issue to the aggregate work status of the firmwares in question with regard to the kernel. So, now that we agreed that those modules need to go into non-free, but that provided their licence is clear enough, like in the tg3 case, they are indeed distriutable in non-free, let's go back to the initial point. This is upstream work, and work which is slowly happening upstream, but will never be ready in time for the etch release. The kernel team has not the ressources to do all that work in a timely fashion for the stated etch release, and delaying until it is ready may mean at least a year of delay for the etch release, which is unacceptable for many. So, if you are really concerned about this issue, start coding, we await your patches impatiently, and will even help you bring them upstream, so they may be integrated in the current debian kernels accordying to our current policy. The firmware loading kernel infrastructure marks a clear lines where an external blob of firmware gets loaded that isn't part of the kernel binary itself. Well, i would say that a single variable symbol is as much of a clean boundary. The firmware loading infrastructure assuredly cannot contain less information than
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
Sven Luther [EMAIL PROTECTED] writes: So, now that we agreed that those modules need to go into non-free, but that provided their licence is clear enough, like in the tg3 case, they are indeed distriutable in non-free, let's go back to the initial point. This is upstream work, and work which is slowly happening upstream, but will never be ready in time for the etch release. The kernel team has not the ressources to do all that work in a timely fashion for the stated etch release, and delaying until it is ready may mean at least a year of delay for the etch release, which is unacceptable for many. Upstream is not doing it and Debian has written it on their flag (DFSG and SC) to get it done. That means Debian has to do it. If that means etch will be delayed a year then etch will be delayed one year. THAT fact was the begining of the thread. Showing that the kernel is not ready to be frozen in accordance to the timeline because the firmware is still not removed. If you can't live with that delay then please start a GR to get an exemption like sarge had. I don't think there has to be more arguing about it anymore. Friendly, Sven Luther MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
Goswin von Brederlow wrote: ramdisk package list has no support for per-flavour module selection, and you have to end up with stuff like the netboot64 list, which has as sole usage to add the ibm power hypervisor and virtualization modules, all an ugly mess. Something to improve. No argument for or against your proposal. I thought I'd respond to this, not because it's the first case of Sven posting incorrect information to this thread, but because it's one of the more egrarious. Quoting debian-installer/build/README: * 'pkg-lists' has subdirectories for the different image types that list udebs that are put on each image. The pkg-lists/*/common files list udebs common to all architectures, and the files named by architecture (arch.cfg) list udebs specific to an architecture. It is also possible to include udebs only on a specific subarchitecture by creating a directory for the architecture and putting config files for the subarchitecture there (arch/subarch.cfg). If you take a look at pkg-lists/netboot, you'll find things like: [EMAIL PROTECTED]:~/src/d-i/installer/build/pkg-lists/netboot/arml ads.cfg netwinder.cfg nslu2.cfg [EMAIL PROTECTED]:~/src/d-i/installer/build/pkg-lists/netboot/sparcl combined.cfg sparc32.cfg sparc64.cfg [EMAIL PROTECTED]:~/src/d-i/installer/build/pkg-lists/netboot/mipsell bcm947xx.cfg cobalt.cfg r3k-kn02.cfg r4k-kn04.cfg sb1-bcm91250a.cfg In fact, powerpc is the only architecture to use unnecessary hacks like netboot64, cdrom64, and netboot-apus. I'd be very happy if someone who cares about powerpc subarches and can read and understand documentation like the above could clean this up (if such a person exists). -- see shy jo signature.asc Description: Digital signature
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On Sun, Aug 13, 2006 at 07:14:02PM +0200, Goswin von Brederlow wrote: Sven Luther [EMAIL PROTECTED] writes: On Sun, Aug 13, 2006 at 03:47:13AM +0200, Goswin von Brederlow wrote: The whole concept is of an extreme fragility, prone to break again and again, cause lot of work for all involved, who become irritable, and bash on you when you even mention it. I did it when working on the amd64 D-I for sarge. I found it quite trivial to do, a matter of minutes. In fact a hell of a lot simpler and way faster than getting the linux-2.6 source package to do something for me. Naturally, amd64 being one of the mainstream arches the d-i team cares about. No they didn't since amd64 was not official or even liked. It didn't even exist before I cloned the i386 config and adjusted them to fit. Let's say that the amd64 arch is very very near the x86 one in design. After all it is just a followup of the later. Into the SuSe/RH source? Not likely. And kernel-package doesn't deal with prebuild binaries. kernel-package deals with creating kernel .debs. You need kernel .debs to use kernel-wedge, at least this is the way it is designed to work, so you lose nothing there. You do have raised some points of improvement for kernel-wedge. Like automaticaly adjusting to changed .config files or some other magics you mentioned. And some points for building module udebs from within linux-2.6 source although I don't agree with you there. Why not ? It is the only way we can bring down the delay for security builds with abi change to the minimum time, and the less human intervention. I don't see security for the installer as a top priority. It is not like people will burn their daily security patched D-I image. It is not like the security team does do security releases for D-I. For stable that seems to get totaly ignored. Indeed, but this is mostly because due to those issues they are incapable of handling those security issues in a timely fashion. D-I in testing/sid, especially the daylies, are for developing. Not to run a secure and stable system. The have bugs, they have security flaws, they might not work at all. That is what unstable is. My main problem is that sarge released with a remote root security hole, which was known and publicized a few month before the actual release, which means all sarge systems are potentially unsecure. The d-i team only needs to handle a list of the modules it want to include in this or that ramdisk, and all will work automatically. Which has the same problem as the kernel-wedge configuration has now when splitting the modules. When a module gets added or removed the list has to be adjusted. Err, no, because the list would be handled in the debian-installer package or its devel tree in the svn repo, and not inside kernel-wedge. Moving the problem from A to B. Doesn't matter what svn repository it is in. Yes, it does matter. If it is inside kernel-wedge, you need to upload kernel wedge to benefit from any fix, while if it is in d-i, you can just build the out-of-svn tree and be happy. Notice that we already have the mapping of module .udeb packages to d-i images in d-i proper, which needs to be done anyway in addition to the kernel-wedge/linux-xxx-di work. Furthermore with the current situation, and given that not all modules are built the same on all arches, and that binary size vary per arch, you end up in an unholy mess when trying to build space constrained ramdisks, like the floppy ones for example. That just means that you need per arch lists of modules. And kernel-wedge has that. Having each module as udeb doesn't change the Kernel-wedge has no per arch list of modules, those are in the 12+ individual linux-*-di packages. fact that you have a unholy mess what modules to put in the image. You don't have an unholy mess, since you can select exactly what modules need to go into each image, a simple list or a hierarchical per arch/subarch/flavour list. Compared to the current case, where you have to upload two packages to be able to modify the list included in d-i. Furthermore, the build, failure, check what the heck kernel module has changed name or dissapeared, or whatnot, is a *ROYAL PAIN*, and very much time consuming., especially on slow arches with lot of flavours. A factor of 1 or so faster than building the linux-2.6 source. As combined time the kernel-wedge time is neglible. Ah, but the beauty of my proposal is that you have tool which handles the config files and module-as-udebs without needing to do a full build. Like Bastian created the nice debian/rules target to check all config options. Furthermore, given that you need to install the kernel image package, you can't even start to autobuild that without hosing the autobuilders. Last I use kernel-wedge, and this is ~2 years ago now, you could build all kernel udebs on a single
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On Sat, Aug 12, 2006 at 12:46:18AM +0200, Goswin von Brederlow wrote: Sven Luther [EMAIL PROTECTED] writes: On Thu, Aug 10, 2006 at 06:14:08PM +0200, Goswin von Brederlow wrote: Sven Luther [EMAIL PROTECTED] writes: Where people buy their hardware or how free their hardware is has little to do with Debian main. It is a problem for the linux upostream authors to support the hardware with free source code and sometimes they fail. Indeed. but when you mention GPL violation, it means that you are not allowed to distribute the whole linux kernel, even in non-free. Hence the need to fix them. Indeed, and this was done for tg3/broadcom, and the qlsomething ones. Those files are now correctly licenced, but are still non-free, and it is this second issue that we are discussing here. And actualy just recently the first one was uploaded to non-free including udebs: http://ftp.debian.org/debian/pool/non-free/f/firmware-non-free/ Now the DAK must be configured to create a dists/sid/non-free/debian-installer/ subdir and index files for the udebs. But I feel we are already one step closer to the goal. Step 1: Create non-free udebs. *checked* Step 2: Add DAK config *waiting for ftp-masters* Step 3: Add D-I support I would propose something even more advanced, and not put the kernel .udebs into the main debian-installer thing, but into a separate section. The way i envision this, we would create a debian/sid/main|non-free/kernel section, where the kernel .udebs would be hold, and we start building them from the main kernel package. Ideally, we would go a step further, and have debian/sid/main|non-free/kernel/flavour sections, so we can split the kernel .udeb packages in a finer grain, and each running installer will only be seeing the modules corresponding to the kernel flavour he is running. This was my proposal from the start, and if you think down to it, it is the best solution for all the kernel/d-i related problems, and would allow to complete the work started with the common packaging, into a solution where there will be only a single package build, easily doable on the usual buildd network, will allow the most flexible solution for abi bumps and security upgrades. But then, i was not able to complete these ideas, due to my mothers illness and death, and the inexcusable behaviour of the d-i folk, frans at the foremost of them. They prefer to keep the status quo, and do lot of work, and complain about abi changes, as well as being able to blame the lazy porters (direct quotation of joey hess) for any problem. This is the thing which led me in clash with them. They perfectly knew about various d-i brokeness in the buildd, chose not to say anything to the porters, and because i was not attent enough to the issue to notice immediately, because i was at my mothers ill-bed, they chose to bash me and subsequently kick me out. This is the worse behaviour that i have seen from any DD so far, even jonathan and even Andrew had more decent behaviour than this, and the worse of this is that none of the others involved, not evben the DPL, have found anything wrong with this behaviour, or at least dared to say something about it, in fear to that frans would be pissed and leave, and they would miss the work he has been doing on d-i. So, you see, if i am angry and hurt, and you dislike me repeating it always, you know who to blame. You can always write patches and send them to the BTS. If you fear retribution by Frans then go that way and get a fellow kernel team member to commit the changes. I feel for you and know that that is awkward but that is how it is currently. If your desire to help is greater than the obstacles then stick with it. I will only go this way so far, but someday, i will fork d-i, and declare them obsolet, and do my stuff as i see fit, and let them the hurdle to catch up if they like. Friendly, Sven Luther Luckily Debian is about free software so you can do that. But please just do and not repeat the story and fork thread over and over. Even I get sick of it and I liked you when we happened to meet in person. Yeah, but notice that if the d-i team had not chosen to kick me out while i was hurt and crying for the death of my mother, none of this would be happening, and we would all code happily thereafter. I asked the DPL to mediate this, but the only conclusion was that i should fork, which is not satisfactory. It has been going on since april, and the more i came to think of it, the more i feel that their behaviour (Frans, joeyh, but also those others who approved or at least didn't contradict them), was the worse that any DD ever did, even worse thanb Andrew asking we don't offer our condoleances to Jens wife, and that was already very grob. So, if you like to be around with people with total lack of human decency, then you should accept when they are criticized for it. Friendly, Sven
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On Sat, 12 Aug 2006 08:40:44 +0200 Sven Luther wrote: So, if you like to be around with people with total lack of human decency, then you should accept when they are criticized for it. And/or you should stop repeating yourself. -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ - Enden er nær: http://www.shibumi.org/eoti.htm pgpPd3wkOTVKE.pgp Description: PGP signature
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
CC limited to debian-kernel as this isn't for release anymore. Sven Luther [EMAIL PROTECTED] writes: On Sat, Aug 12, 2006 at 12:46:18AM +0200, Goswin von Brederlow wrote: And actualy just recently the first one was uploaded to non-free including udebs: http://ftp.debian.org/debian/pool/non-free/f/firmware-non-free/ Now the DAK must be configured to create a dists/sid/non-free/debian-installer/ subdir and index files for the udebs. But I feel we are already one step closer to the goal. Step 1: Create non-free udebs. *checked* Step 2: Add DAK config *waiting for ftp-masters* Step 3: Add D-I support I would propose something even more advanced, and not put the kernel .udebs into the main debian-installer thing, but into a separate section. The way i envision this, we would create a debian/sid/main|non-free/kernel section, where the kernel .udebs would be hold, and we start building them from the main kernel package. Ideally, we would go a step further, and have debian/sid/main|non-free/kernel/flavour sections, so we can split the kernel .udeb packages in a finer grain, and each running installer will only be seeing the modules corresponding to the kernel flavour he is running. What for? The installer always needs the installer udebs. Having the kernel udebs in another section just means more files to generate and to download that can go wrong. It saves nothing. Splitting the udebs by flavour would save a few bytes on the Packages file but the only affect that has would be a few bytes less downloaded (inconsequential) and a few bytes less ram used (if you are that low then you have problems anyway). If you want the user to only see the kernel components that match the running kernel then filter them in the display. I don't think splintering the Index files into tons of sections is the way to go there. Also think about what that would mean for a newly added kernel flavour in terms of delays till the DAK gets reconfigured for a new section. This was my proposal from the start, and if you think down to it, it is the best solution for all the kernel/d-i related problems, and would allow to complete the work started with the common packaging, into a solution where there will be only a single package build, easily doable on the usual buildd network, will allow the most flexible solution for abi bumps and security upgrades. The layout of the Index files and sections used has absoluetly no effect on either abi bumps nor security nor in any way the package building. Extra sections just means much more work for the DAK with little to no benefit. I don't even consider that a good solution. Quite opposite. The requirement of a new section for a new kernel flavour would create a lot of delays for the kernel-team when adding a new flavour. But then, i was not able to complete these ideas, due to my mothers illness ... And there you go again. STOP IT PLEASE. It is totaly off-topic. ... So, you see, if i am angry and hurt, and you dislike me repeating it always, you know who to blame. You for repeating it over and over. With every repetition the precieved blames shifts a little bit to your side until all people see precieve is that you are to blame. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On Sat, Aug 12, 2006 at 03:13:13PM +0200, Goswin von Brederlow wrote: CC limited to debian-kernel as this isn't for release anymore. Sven Luther [EMAIL PROTECTED] writes: On Sat, Aug 12, 2006 at 12:46:18AM +0200, Goswin von Brederlow wrote: And actualy just recently the first one was uploaded to non-free including udebs: http://ftp.debian.org/debian/pool/non-free/f/firmware-non-free/ Now the DAK must be configured to create a dists/sid/non-free/debian-installer/ subdir and index files for the udebs. But I feel we are already one step closer to the goal. Step 1: Create non-free udebs. *checked* Step 2: Add DAK config *waiting for ftp-masters* Step 3: Add D-I support I would propose something even more advanced, and not put the kernel .udebs into the main debian-installer thing, but into a separate section. The way i envision this, we would create a debian/sid/main|non-free/kernel section, where the kernel .udebs would be hold, and we start building them from the main kernel package. Ideally, we would go a step further, and have debian/sid/main|non-free/kernel/flavour sections, so we can split the kernel .udeb packages in a finer grain, and each running installer will only be seeing the modules corresponding to the kernel flavour he is running. What for? The installer always needs the installer udebs. Having the kernel udebs in another section just means more files to generate and to download that can go wrong. It saves nothing. The installer needs the installer .udebs of the flavours it is using, but hardly any others. This mean we would save on memory space used to hold the 3 in-memory copy of the Packages file. Splitting the udebs by flavour would save a few bytes on the Packages file but the only affect that has would be a few bytes less downloaded (inconsequential) and a few bytes less ram used (if you are that low then you have problems anyway). But it would make space for a more fine-grained .udeb classification, which would in turn result in a considerable memory and bandwidth saving, as only the modules really used are downloaded. Furthermore this will allow the kernel .udebs to be moved into the common kernel package, without costing the installer folk any flexibility, as they will not have need to balance the module .udebs and thus keep control of them. Furthermore, with a set of smart tools, some Makefile/Kconfig analysis, and a bit of graph theory, it would allow to automate the module .udeb creation, based only on the choice of .config options, and thus make the job of the porters so much easier, needing only to consider the config options one single time, to see if they need to be enabled, and then decide if this particular option is one which would enable a module which would be needed for the installer. All the rest, the description, the depednecy graph, etc, will be taken from the kernel source directly (with a few overrides for dependencies for some modules who do not (yet maybe) carry the dependency information in their source code. If you want the user to only see the kernel components that match the running kernel then filter them in the display. I don't think Well, apart from the installer pulling some 2.4.27-apus .udebs in on a 2.6.12-powerpc flavour, which is indeed a mistake which would be solved by this solution, this is hardly the point. The main point here, is that it is easily doable to automate a set of tasks, and to keep only the small minimum set of human decision in a single place, and thus spare everyone a lot of work, which is after all what computers where invented for in the first place. Compare this to the current situation, favored by the installer team, probably just to oppose me, where every porter has to redo the module selection job by hand, where none of them are informed about the problems faced by the others, where a slight indisponibility of one of the porters result in thee brokeness of the related build, and accusations of lazyness by the d-i leaders, and you see how this would be dissatisfying, and how the d-i leaders in their pettiness see my technical proposals as an attack against their supremacy. splintering the Index files into tons of sections is the way to go there. Also think about what that would mean for a newly added kernel flavour in terms of delays till the DAK gets reconfigured for a new section. Indeed. But then, there is probably another set of modifications that could be done to help this go around. The kernel team has already stated that they are not really happy in the way of how NEW is handled in relation of kernels. Another solution to the non-free DFSG mess and this would be to take the kernel fully out of debian, and have our own infrastructure to handle it as we see fit. This would solve the problem of those people in debian who like to do unneeded work, and impose unduly delays to other teams. This was my proposal from the start,
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On Sat, Aug 12, 2006 at 07:46:16PM +0200, Goswin von Brederlow wrote: Sven Luther [EMAIL PROTECTED] writes: What for? The installer always needs the installer udebs. Having the kernel udebs in another section just means more files to generate and to download that can go wrong. It saves nothing. The installer needs the installer .udebs of the flavours it is using, but hardly any others. This mean we would save on memory space used to hold the 3 in-memory copy of the Packages file. -rw-r--r-- 1 reprepro nogroup 187K Aug 11 04:53 dists/sid/main/debian-installer/binary-amd64/Packages Is that really a problem? If so then work on reducing the number of copies from 3 to 1 plus a compressed one. You could also filter out kernel modules for other flavours while downloading the file prior top saving it. For more space filter out all the udebs already installed too. Having all the udebs in one Packages file is convenient for debian-installer when building, for debian-cd, for mirror scripts and so on. Don't forget that. And don't forget that the businesscard or netinst CDs have filtered Packages files for the udebs with only the right udebs in there. Only the netboot and full CD images waste those few Kb. Splitting the udebs by flavour would save a few bytes on the Packages file but the only affect that has would be a few bytes less downloaded (inconsequential) and a few bytes less ram used (if you are that low then you have problems anyway). But it would make space for a more fine-grained .udeb classification, which would in turn result in a considerable memory and bandwidth saving, as only the modules really used are downloaded. Furthermore this will allow the kernel .udebs to be moved into the common kernel package, without costing the installer folk any flexibility, as they will not have need to balance the module .udebs and thus keep control of them. More udebs increases the Packages files. That works contrary to what Indeed. The proposal to split the packages file in a per flavour kernel repository comes directly from the need to counterbalance this augmentation of the number of packages. Also, do you really need a gazillion of not-for-your-hardware modules installed ? you want (save space). As for saving download bandwith, saving 1MB of udebs compared to the 500-2000MB debs of a normal install is quite incosequential. You might be optimizing at the wrong end here. Indeed. I also see how more sections would change any of this? Has someone said we can't do finer grained kernel module udebs because the Packages file will grow to big with all those udebs? I think a far Indeed, this was the main critic against the finer grained module proposal (apart from all the hateful stuff they said to me at the same time naturally). bigger reason would be flooding NEW with so many tiny udebs on an ABI change and thus driving ftp-master nuts. Nope, because they would all be part of the same source package, and i think they can easily enough authorize all binaries of a single source package. Furthermore, with a set of smart tools, some Makefile/Kconfig analysis, and a bit of graph theory, it would allow to automate the module .udeb creation, based only on the choice of .config options, and thus make the job of the porters so much easier, needing only to consider the config options one single time, to see if they need to be enabled, and then decide if this particular option is one which would enable a module which would be needed for the installer. All the rest, the description, the depednecy graph, etc, will be taken from the kernel source directly (with a few overrides for dependencies for some modules who do not (yet maybe) carry the dependency information in their source code. You can already do that. Just because the modules are not copied into udebs at the end does not mean you can't pretend. Just imagine they get copied and do all your magic. After that you have a set of modules and the depmod file for them that D-I uses to split modules into udebs. the depmod file that D-I uses to split modules into .udebs. You must be living in another planet than me. Right now the modules are split manually, in a stupid painstakingly repetitive and time-consuming way. And you can't even per-arch/subarch override properly the default choice done in kernel-wedge. Notice also that the apus flavour was killed from d-i once they kicked me out, because it was too much work for them to fix it. If you want the user to only see the kernel components that match the running kernel then filter them in the display. I don't think Well, apart from the installer pulling some 2.4.27-apus .udebs in on a 2.6.12-powerpc flavour, which is indeed a mistake which would be solved by this solution, this is hardly the point. The main point here, is that it is easily doable to automate a set of tasks, and to keep
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
[EMAIL PROTECTED] (Marco d'Itri) writes: On Aug 07, Goswin von Brederlow [EMAIL PROTECTED] wrote: No, because those are not linked together with the GPLed code, but are a mere aggregation of works inside the same media, i.e. the binary file. Those non-free firmware will never run inside the same memory space as the kernel, and are offloaded to a peripheral processor, and the communication media between the kernel and this peripheral processor running said firmware is clearly defined, there is no doubt that those non-free firmware do not break the kernel GPL. They are linked in, they have symbols, the code directly references their address. Can you name one tool that will easily remove such No. They are a char array, it's data copied where the hardware wants it. It's not code called by other functions. That still leaves the symbol for the variable holding the char array and its size. The code copying the data references that variable and size. I didn't say the code is called. Compare it to including a hexdump of an image or sound in a header file and including that in the binary. And compare it with having that same image or sound as external file shipped in the same deb. Assume the image/sound was rendered/generated from some source format not included in the source. E.g. povray input. Is it an aggregation with the image linked into the binary? aggregated code from the kernel image? Not relevant. If it is an aggregation then there must be a way to break it up and only keep the GPLed parts. I think that is very much relevant. I don't think you can call something an aggregation if it is inseperably bound together. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On Sat, Aug 12, 2006 at 10:32:54PM +0200, Goswin von Brederlow wrote: Indeed. The proposal to split the packages file in a per flavour kernel repository comes directly from the need to counterbalance this augmentation of the number of packages. So instead of having 5 module udebs for my ONE generic kernel I get 200? For say amd64 it would be a big step back. Indeed, but smaller ones. How many archs with flavours are we talking about anyway? I think m68k has 3 flavours and ppc some and every other archs has a generic flavour or drivers buildin already. I know that the more exotic ones have many flavours. Also, the amount of packages will be proportional of the non-builtin drivers. POwerpc has currently 5 d-i flavours (or would have if the new d-i powerpc people did they work correctly), powerpc, powerpc64, powerpc-miboot, prep and apus. Also, do you really need a gazillion of not-for-your-hardware modules installed ? All my hardware (that includes m68k) has absolutley 0 problems with that. They will be installed in D-I and they will be installed on the finished system. No point breaking my neck to get less installed during D-I. you want (save space). As for saving download bandwith, saving 1MB of udebs compared to the 500-2000MB debs of a normal install is quite incosequential. You might be optimizing at the wrong end here. Indeed. So why then do you want to split module udebs? Because the current way of doing it is problematic. The d-i folk don't want to give control of it to the kernel team, and the new proposal handled they keeping the same and even better control of how to build the ramdisks, while at the same time building the module .udebs from the common kernel source, thus saving around 2 weeks of time the d-i folk need to adjust to a new abi or version, thus making for more timely kernel security updates, and making the work of the divers security teams easier. You just agreed that downloading the module udebs is inconsequential given their size. You agreed that more udebs increases the Index files which is bad. Err, let's say we have 5 flavours like on powerpc, and each would have 200+ little module .udebs, which gives us Package numbers of 1000+. Worse if there are more flavours. This is the part that joeyh objected to this plan of spliting modules because of the fact that d-i loads three in memory copy of the Packages file, which in turn prompted the idea of per-flavour repositories. If you look at the whole idea though, you find out that it is a really neat solution to this problem, it cares for all the technical hurdles, and is elegant and nice, and if you throw in the part that can be automated, it saves work for everyone involved. In my book, this makes it a good idea, or at least something that should be tried, and not something you have to menace the implementator so he doesn't dare pursue it. So all I'm left with is that you don't end up with as much modules in the ramdisk. Something I find irelevant unless you talk about the low-mem flavour. And the fact that it is much easier to update config option and add and remove new modules doesn't count. Naturally, you don't handle kernel .udebs. I did, and it was a royal pain in the ass to handle those, it took me hours, for stuff that was already done 10 times for the other flavours. And even a few days ago, the powerpc64 flavour was still broken with the 2.6.17 kernels, because some random module listed in the list of modules was not present. The whole concept is of an extreme fragility, prone to break again and again, cause lot of work for all involved, who become irritable, and bash on you when you even mention it. This, in my book, is not an example of good software engineering, and any proposal to help improve this should be worth considering. Is the space taken up by the installed modules your actual argument for having finer grained module udebs? Nope, but then i told you that in the first mail already :) ... You can already do that. Just because the modules are not copied into udebs at the end does not mean you can't pretend. Just imagine they get copied and do all your magic. After that you have a set of modules and the depmod file for them that D-I uses to split modules into udebs. the depmod file that D-I uses to split modules into .udebs. You must be living in another planet than me. Right now the modules are split manually, in a stupid painstakingly repetitive and time-consuming way. And you can't even per-arch/subarch override properly the default choice done in kernel-wedge. Last I used it, and that is some time ago, the dependencies where automatically checked on build. Maybe someone broke that but that could be repaired easily enough. The dependencies, yes, with a manual override which you have to use in mysterious cases. The actual module list is fully manually handled, in 2 places for each arch, and if you happen to not build a
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On Sat, Aug 12, 2006 at 11:03:29PM +0200, Goswin von Brederlow wrote: [EMAIL PROTECTED] (Marco d'Itri) writes: On Aug 07, Goswin von Brederlow [EMAIL PROTECTED] wrote: No, because those are not linked together with the GPLed code, but are a mere aggregation of works inside the same media, i.e. the binary file. Those non-free firmware will never run inside the same memory space as the kernel, and are offloaded to a peripheral processor, and the communication media between the kernel and this peripheral processor running said firmware is clearly defined, there is no doubt that those non-free firmware do not break the kernel GPL. They are linked in, they have symbols, the code directly references their address. Can you name one tool that will easily remove such No. They are a char array, it's data copied where the hardware wants it. It's not code called by other functions. That still leaves the symbol for the variable holding the char array and its size. The code copying the data references that variable and size. I didn't say the code is called. Yeah, thanks very much. I suggest you go over to the FSF site, and read the GPL faq, and then come back and discuss this again. I did so during that discussion last year, and as said, that argumentation convinced the broadcom legal department, and even the FSF had nothing to say against it. A quick clue to help your search, the important parts are the one about the 'significant interface' or something such, and i seriously doubt that having a single variable referencing the non-free stuff is enough for that. Or else, consider this in a different way. On your computer disk, you have a bunch of binary files, those are called partitions, and hold data in a filesystem format. If you have any part of a GPLed binary on that filesystem, which is referenced by an inode or similar, and a non-free work (and you have probably bunch of unlicenced non-free stuff, like this email for example), referenced by another inode, then this doesn't make this email a derivative work of the linux kernel. Compare it to including a hexdump of an image or sound in a header file and including that in the binary. And compare it with having that same image or sound as external file shipped in the same deb. Well, the FSF argues that it is not important where the file is, as long as there is a logical link, in order to have the GPL cross the dynamic linking barrier. In the same way, the only relationship of the non-free firmware or your image or sound, is that it is transported in the same binary, and used as data offloaded to the peripheral device. Assume the image/sound was rendered/generated from some source format not included in the source. E.g. povray input. So ? What has this to do with it ? Is it an aggregation with the image linked into the binary? It depends if your binary is an image compressor, and only transports the image, or if said image is used in the binary for icons of its GUI for example or as splash screen. aggregated code from the kernel image? Not relevant. If it is an aggregation then there must be a way to break it up and only keep the GPLed parts. I think that is very much relevant. I don't think you can call something an aggregation if it is inseperably bound together. Well, sure there is part to separate them. You could imagine a (non-free) tool called before lilo or grub, and which would upload those firmwares for the peripheral device to be ready when the free driver comes into play. Or you could use the new initramfs/firmware loading kernel infrastructure to separate the firmware from the kernel. Err, is not this latest one what you are suggesting we do ? So, if i understood you well, your own argumentation is hitting you back there, and this is usually proof that there is something terribly wrong in your argumentation to start with. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
Sven Luther [EMAIL PROTECTED] writes: On Sat, Aug 12, 2006 at 10:32:54PM +0200, Goswin von Brederlow wrote: Indeed. The proposal to split the packages file in a per flavour kernel repository comes directly from the need to counterbalance this augmentation of the number of packages. So instead of having 5 module udebs for my ONE generic kernel I get 200? For say amd64 it would be a big step back. Indeed, but smaller ones. How many archs with flavours are we talking about anyway? I think m68k has 3 flavours and ppc some and every other archs has a generic flavour or drivers buildin already. I know that the more exotic ones have many flavours. Also, the amount of packages will be proportional of the non-builtin drivers. POwerpc has currently 5 d-i flavours (or would have if the new d-i powerpc people did they work correctly), powerpc, powerpc64, powerpc-miboot, prep and apus. So the worst case is 5 flavours while most archs have only one. Your solution would cut the number of kernel udebs by at most a factor of 5 while you want to increase by a factor of 40. That is still a net loss by a factor of 8 for 5 flavours. So why then do you want to split module udebs? Because the current way of doing it is problematic. The d-i folk don't want to give control of it to the kernel team, and the new proposal handled they keeping the same and even better control of how to build the ramdisks, while at the same time building the module .udebs from the common kernel source, thus saving around 2 weeks of time the d-i folk need to adjust to a new abi or version, thus making for more timely kernel security updates, and making the work of the divers security teams easier. Who controls the udebs has nothing to do with splitting the module udebs into smaller chunks. You could split them while D-I has control of them or have them build by the kernel team and not split them up further or do both. The two issues are independent of each other. You just agreed that downloading the module udebs is inconsequential given their size. You agreed that more udebs increases the Index files which is bad. Err, let's say we have 5 flavours like on powerpc, and each would have 200+ little module .udebs, which gives us Package numbers of 1000+. Worse if there are more flavours. This is the part that joeyh objected to this plan of spliting modules because of the fact that d-i loads three in memory copy of the Packages file, which in turn prompted the idea of per-flavour repositories. If you look at the whole idea though, you find out that it is a really neat solution to this problem, it cares for all the technical hurdles, and is elegant and nice, and if you throw in the part that can be automated, it saves work for everyone involved. Say you do get your per flavour split despite increasing the number of kernel modules worst arch has to deal with by a factor of 8 and for most archs a factor of 40. Can you imaging the poor users of a low-mem system going through the list of 200+ components to pick out the right modules to download? Neat? In my book, this makes it a good idea, or at least something that should be tried, and not something you have to menace the implementator so he doesn't dare pursue it. So all I'm left with is that you don't end up with as much modules in the ramdisk. Something I find irelevant unless you talk about the low-mem flavour. And the fact that it is much easier to update config option and add and remove new modules doesn't count. Naturally, you don't handle kernel .udebs. I did, and it was a royal pain in the ass to handle those, it took me hours, for stuff that was already done 10 times for the other flavours. And even a few days ago, the powerpc64 flavour was still broken with the 2.6.17 kernels, because some random module listed in the list of modules was not present. The whole concept is of an extreme fragility, prone to break again and again, cause lot of work for all involved, who become irritable, and bash on you when you even mention it. I did it when working on the amd64 D-I for sarge. I found it quite trivial to do, a matter of minutes. In fact a hell of a lot simpler and way faster than getting the linux-2.6 source package to do something for me. The kernel-wedge lists do break from time to time but they are simple to adjust and quick to rebuild. And another advantage with kernel-wedge: You can easily take your (maybe even prebuild) custom kernel and create udebs from it. I would hate to have to add the SuSe or RH patch sets to the linux-2.6 source to build kernel udebs for hardware that requires their patches. This, in my book, is not an example of good software engineering, and any proposal to help improve this should be worth considering. Still not convinced. You do have some points but I see more drawbacks and problems than advantages. Is the space taken up by the installed modules your actual argument for having finer
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
Goswin von Brederlow [EMAIL PROTECTED] writes: Is it an aggregation with the image linked into the binary? It doesn't matter for Debian's purposes. While the GPL permits shipping a GPL'd program merely aggregated alongside a non-free program, we don't ship the nonfree part no matter what, so it hardly matters to us whether it's also a GPL violation. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
Sven Luther [EMAIL PROTECTED] writes: On Sat, Aug 12, 2006 at 11:03:29PM +0200, Goswin von Brederlow wrote: Compare it to including a hexdump of an image or sound in a header file and including that in the binary. And compare it with having that same image or sound as external file shipped in the same deb. Well, the FSF argues that it is not important where the file is, as long as there is a logical link, in order to have the GPL cross the dynamic linking barrier. In the same way, the only relationship of the non-free firmware or your image or sound, is that it is transported in the same binary, and used as data offloaded to the peripheral device. Assume the image/sound was rendered/generated from some source format not included in the source. E.g. povray input. So ? What has this to do with it ? So you can't claim the hexdump (or binary file) is the prefered form of modification (source). Is it an aggregation with the image linked into the binary? It depends if your binary is an image compressor, and only transports the image, or if said image is used in the binary for icons of its GUI for example or as splash screen. If I just dump my hexcode of the image/sound to my black box (qiv or xmms for example) for (dis)playing then I only transport the file. If I (dis)play it myself then it isn't an aggregation. Intresting. Or does the black box have to be hardware? aggregated code from the kernel image? Not relevant. If it is an aggregation then there must be a way to break it up and only keep the GPLed parts. I think that is very much relevant. I don't think you can call something an aggregation if it is inseperably bound together. Well, sure there is part to separate them. You could imagine a (non-free) tool called before lilo or grub, and which would upload those firmwares for the peripheral device to be ready when the free driver comes into play. I can imagine a tool that rewrites non-free parts of a binary as free software from scratch without breaking any laws about reverse engeneering too. Does that mean they exist or are even possible? no. Or you could use the new initramfs/firmware loading kernel infrastructure to separate the firmware from the kernel. That requires changes in the source. Exactly those changes is what I say must happen. The firmware loading kernel infrastructure marks a clear lines where an external blob of firmware gets loaded that isn't part of the kernel binary itself. Err, is not this latest one what you are suggesting we do ? So, if i understood you well, your own argumentation is hitting you back there, and this is usually proof that there is something terribly wrong in your argumentation to start with. No. You just argumented my point. The source changes to seperate the firmware and to use the firmware loading kernel infrastructure makes a difference imho. Also notice that with the firmware loading kernel infrastructure you can just delete the firmware file and the loader will give a simple error. Good luck trying to remove the char *firmware from a kernel image and not have it crash. Best you can do there is fill it with dummy data. Friendly, Sven Luther MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
Sven Luther [EMAIL PROTECTED] writes: On Thu, Aug 10, 2006 at 06:14:08PM +0200, Goswin von Brederlow wrote: Sven Luther [EMAIL PROTECTED] writes: Where people buy their hardware or how free their hardware is has little to do with Debian main. It is a problem for the linux upostream authors to support the hardware with free source code and sometimes they fail. Indeed. but when you mention GPL violation, it means that you are not allowed to distribute the whole linux kernel, even in non-free. Hence the need to fix them. Indeed, and this was done for tg3/broadcom, and the qlsomething ones. Those files are now correctly licenced, but are still non-free, and it is this second issue that we are discussing here. And actualy just recently the first one was uploaded to non-free including udebs: http://ftp.debian.org/debian/pool/non-free/f/firmware-non-free/ Now the DAK must be configured to create a dists/sid/non-free/debian-installer/ subdir and index files for the udebs. But I feel we are already one step closer to the goal. Step 1: Create non-free udebs. *checked* Step 2: Add DAK config *waiting for ftp-masters* Step 3: Add D-I support You can always write patches and send them to the BTS. If you fear retribution by Frans then go that way and get a fellow kernel team member to commit the changes. I feel for you and know that that is awkward but that is how it is currently. If your desire to help is greater than the obstacles then stick with it. I will only go this way so far, but someday, i will fork d-i, and declare them obsolet, and do my stuff as i see fit, and let them the hurdle to catch up if they like. Friendly, Sven Luther Luckily Debian is about free software so you can do that. But please just do and not repeat the story and fork thread over and over. Even I get sick of it and I liked you when we happened to meet in person. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On Sat, Aug 05, 2006 at 11:29:44PM -0400, Nathanael Nerode wrote: I apologize for responding to Marco's post; in retrospect he was clearly trolling and I should not have responded to him. The point of my initial message was not to argue: it was that the etch timeline is unrealistic, because I see no progress on removing the substantial number of sourceless binaries from the Linux kernel source package, and it's *after* the kernel was supposed to have frozen! Is there a plan for dealing with this fast enough to avoid delaying the release of etch? If so, please post it. Well, there is no way i see that we can deal with this in a timely fashion without delaying etch by a year or so. Remember that d-i and kernel freeze date was planned last week. Furthermore, there is no evidence that future upstream version of the kernel will not add more such non-free firmware, so this would be an ongoing process, and we also have to keep in sync with the upstream efforts to do so. As thus, i think the more reasonable way to handle this, is to not force this to be solved for etch, but let etch be released as is (needs a GR though, but not a 3:1 one), while at the same time start a coordinated process to solve the issue, which would probably be something akin to a never ending work, until upstream uses the no-non-free-firmware policy also. skipped nice plan to file bugs So, the real solution to this would be to setup a, maybe separate, team of folk working on the non-free firmware issue, and proposing patches, patches which have a chance to be merged upstream, to solve this issue. This could overlap with the kernel team, or not, but the patches need to be approved by the kernel team, and forwarded upstream. The kernel team as is should continue focusing on packaging issues and normal maintenance. Now, on how to go forward with this issue, i think the most reasonable way would be for someone caring about the issue (you ?) to take ownership of the wiki page (maybe saving the current content in another page), and start with an exhaustive list, as well as analysis of each individual case. This would be preferable to a bug filing tactic, which would just be lost in the huge load of kernel bug reports anyway, and be more constructive. Maybe open a single bug pointing to said wiki page or something. Once that is done, the real work can start. Notice that the situation has clearly improved upstream with relation to the patches you sent a couple of year back, and which apparently somehow broke the drivers, so now would be a good time to restart that effort. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
Nathanael Nerode wrote: [snip] http://wiki.debian.org/KernelFirmwareLicensing is grossly out-of-date, but I will integrate the relevant information from that in the process. KernelFirmwareLicensing is supposed to track information about mis-licensed firmware. IIRC you mentioned to have found at least one such driver in the Debian kernel, if that's correct, please update the wiki with that information. Please don't use KernelFirmwareLicensing for correctly licensed firmware. Alternative option: the Wiki page could be revived and used to coordinate the process. Unfortunately it's quite out-of-date, and it's unwieldly. You can split a page in several ones, probably per driver directory. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
Sven Luther [EMAIL PROTECTED] writes: On Tue, Aug 08, 2006 at 08:12:48PM -0400, Jim Crilly wrote: On 08/08/06 04:49:33PM -0700, Thomas Bushnell BSG wrote: Sven Luther [EMAIL PROTECTED] writes: Well, it reads to me that we won't screw our users without second thought like some here are proposing. In my opinion, we have been screwing our users for years by lying to them about whether their software was free. We would even say things like hardware such-and-such is supportable with free software and then ship them a non-free driver. I'm sure this has been suggested/covered before, but what's wrong with just sticking those drivers in non-free and giving the user a choice during Well, i mentioned this already elsewhere in this thread, but there you go : 1) it is lot of work, and we (the kernel team) don't realy have the ressources for it. Then stop doing 0 day uploads and fix the kernel. No matter how long it takes. It is a release blocker, etch will wait for you. If you need more help then ask for it (again). Debian-devel-anounce would probably be a good idea. 2) there is currently no exhaustive list of affected drivers, there may even be some case of things like main processor micro-code affected. Fix what you know and keep the rest in blissfull ignorance. 3) it demands works of part of debian outside the kernel team, particularly the d-i and eventually archive folk. The d-i have not been cooperative to this idea, and even mentioning it to them has resulted in a barrage of agresive bashing. But then maybe it was just because they don't like me and i dared to mention this all those months back. In any case, they have not fixed their side of it, and there appears to be no plan to do so, i was kicked out of the d-i project, and Frans threatened me if i even dared work on kernel/d-i based issues. Sorry, that is just no reason to break the social contract and dfsg. Yes you have to break D-I but they can fix it. They have been told about it and are aware of it. Once it becomes virtualy required they will fix it for sure. So far it isn't. As I said before, don't wait for them to work ahead but force the issue on them. The gravity of it requires it. installation? Sure, it'll screw the users that won't have Internet access during the installation, but as long as it's possible to make custom installation discs that'll probably take care of itself. You can do a CD media which includes the non-free modules, you would have to build a non-free d-i image set anyway. Which would be a task for the debian-cd team. Has anyone talk to them about it? Friendly, Sven Luther MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On Thu, Aug 10, 2006 at 03:51:31PM +0200, Goswin von Brederlow wrote: Sven Luther [EMAIL PROTECTED] writes: 1) it is lot of work, and we (the kernel team) don't realy have the ressources for it. Then stop doing 0 day uploads and fix the kernel. No matter how long it takes. It is a release blocker, etch will wait for you. Your patches are welcome. If you need more help then ask for it (again). Debian-devel-anounce would probably be a good idea. Please go ahead and find people willing to work on this, you hardly need our help for this. 2) there is currently no exhaustive list of affected drivers, there may even be some case of things like main processor micro-code affected. Fix what you know and keep the rest in blissfull ignorance. As said, your patches would be wlecome. 3) it demands works of part of debian outside the kernel team, particularly the d-i and eventually archive folk. The d-i have not been cooperative to this idea, and even mentioning it to them has resulted in a barrage of agresive bashing. But then maybe it was just because they don't like me and i dared to mention this all those months back. In any case, they have not fixed their side of it, and there appears to be no plan to do so, i was kicked out of the d-i project, and Frans threatened me if i even dared work on kernel/d-i based issues. Sorry, that is just no reason to break the social contract and dfsg. Yes you have to break D-I but they can fix it. They have been Err, given the way i was bashed the last time this happened, no, sorry, i will not even dare try somethign such in the near future. told about it and are aware of it. Once it becomes virtualy required they will fix it for sure. So far it isn't. As I said before, don't wait for them to work ahead but force the issue on them. The gravity of it requires it. Maybe, but the same could be said of you, you care for this, help us fix it, and then there will be no other choice than follow your lead. As always, patches welcome. installation? Sure, it'll screw the users that won't have Internet access during the installation, but as long as it's possible to make custom installation discs that'll probably take care of itself. You can do a CD media which includes the non-free modules, you would have to build a non-free d-i image set anyway. Which would be a task for the debian-cd team. Has anyone talk to them about it? Currently there is no infrastructure to build non-free d-i images. doing non-free cds would be rather easy, and it is something i can do myself, as i still have svn access to the debian-cd project. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
Sven Luther [EMAIL PROTECTED] writes: On Mon, Aug 07, 2006 at 02:48:08PM +0200, Goswin von Brederlow wrote: Sven Luther [EMAIL PROTECTED] writes: And even for an aggregation of works the DFSG holds and you are still in trouble. Sure, the DFSG says that we need the source code for those, and they are thus non-free, but what i am arguing is that they are not violation of the kernel GPL, since they are separate aggregate works. As part of the source files they are seperate works. When you compile and LINK them all together they become one work. Just like when you link in non GPL static (or even dynamic) libraries. Let me make another example. I take a GPL program and link in a non-free library plus glue code that forks a child and uses the library. Only the child does use the non-free library and the communication between father and child is clearly defined. Let me make another example. You buy a random bunch of hardware, and either run linux on it, or run a free linux driver running it. This hardware in question happens to have some random bios on it, which is non-free, or some fpga config file hidden in a flash. This is exactly the same case as the one you are describing, with the sole exception of the firmware in question being temporarily transported in the kernel binary and uploaded in the device. No, to get the same case you have to read out the bios/flash and include that in Debian to be distributed by debian in main. If you do that the hardware vendor would sue you in a minute for copyright infringement because you don't even have distribution rights. Finally, what you mention is more akin to the unicorn driver, which is a driver for a soft-ADSL pci modem, which links to a non-free, binary-only, x86-only ADSL library. This is indeed more than just agregation, and after i engaged bewan over it, and we consulted with RMS and the FSF, they released their drivers with a GPL+exception licence, and the package is now happily sitting in non-free, waiting for someone to write a free ADSL library replacement. Indeed. That was one of the bad examples. The non-free library never runs in the same address space as the rest of the program. Does that mean this is just an aggregation of works and GPL compliant? I am not familiar enough with how library are run, but there is some very different way in which libraries called by programs work, and the way the main cpu interacts with a peripheral processor on a pci card, don't you think ? Or do you want also to declare that you can run GPLed Linux kernels only on hardware whose VHDL of every chip on it as well as schematics and gerbers are freely available, not counting that you would also need free PCB design tools which can read the format, as well as free tools running the manufacturing plant, and so on ... _IF_ Debian would distribute the CPU in main then zes, I would require that. But Debian is not a hardware vendor. Where people buy their hardware or how free their hardware is has little to do with Debian main. It is a problem for the linux upostream authors to support the hardware with free source code and sometimes they fail. I've been bugging Bastian about this issue as well since I need this for multiarch. I have a hacked together cdebootstrap that first concatenates the Packages files from multiple sources and then calls libd-i. It is ugly but it works. This workaround is quite simple to copy into D-I if you really want to work on it. Ah, nice, i would really be interested in that. Now, the problem is that it needs to be integrated into the main d-i work, and given their over-conservativeness and immobilism, it is way too late for etch, or didn't you hear that d-i was supposed to be frozen this week ? Please stop making this into an attack. Better spend that energy into writing a patch. You've done D-I work before so maybe you even looked at libd-i source before. Nope, i keep pointing out the responsabilities of the current mess to where it belongs. I don't care about the d-i guys, the DPL clearly said i should expect nothing of them (well, of a few of them), and fork d-i, so ... But finger pointing will get no work done. Just annoy people. If the kernel is split up then D-I not handling non-free will be a release blocker and will be solved. I don't think compromising ideals because D-I doesn't yet handle non-free is the right thing to do. It is not like implementing this will take more than a weekend. Maybe, but without me stepping up, and pointing the finger to this problem, nobody would have cared, probably they would have been afraid to suffer the same treatement i got at their hands for daring mention those problems. You are not stepping up. So far you are just pointing fingers. And so far I haven't seen anybody care that didn't care already. I care and I'm not afraid to suffer your treatment because I always got the treatment that I deserve from the D-I team and to some extend
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
Sven Luther [EMAIL PROTECTED] writes: On Thu, Aug 10, 2006 at 03:51:31PM +0200, Goswin von Brederlow wrote: Sven Luther [EMAIL PROTECTED] writes: Which would be a task for the debian-cd team. Has anyone talk to them about it? Currently there is no infrastructure to build non-free d-i images. doing non-free cds would be rather easy, and it is something i can do myself, as i still have svn access to the debian-cd project. Friendly, Sven Luther There we go. Something constructive for you to do that you are intrested in anyway. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On Thu, Aug 10, 2006 at 04:32:52PM +0200, Goswin von Brederlow wrote: Sven Luther [EMAIL PROTECTED] writes: On Mon, Aug 07, 2006 at 02:48:08PM +0200, Goswin von Brederlow wrote: Sven Luther [EMAIL PROTECTED] writes: And even for an aggregation of works the DFSG holds and you are still in trouble. Sure, the DFSG says that we need the source code for those, and they are thus non-free, but what i am arguing is that they are not violation of the kernel GPL, since they are separate aggregate works. As part of the source files they are seperate works. When you compile and LINK them all together they become one work. Just like when you link in non GPL static (or even dynamic) libraries. Please read last years discussion on debian-legal where this was exposed in detail, and a consensus was found which i reflect in my position here. Think of the case of a windows compression program which produce binaries with builtin uncompressor binaries. What you claim is that using those (winzip and co) to compress the linux kernel source would break the GPL, because they are physically housed in the same binary. Let me make another example. I take a GPL program and link in a non-free library plus glue code that forks a child and uses the library. Only the child does use the non-free library and the communication between father and child is clearly defined. Let me make another example. You buy a random bunch of hardware, and either run linux on it, or run a free linux driver running it. This hardware in question happens to have some random bios on it, which is non-free, or some fpga config file hidden in a flash. This is exactly the same case as the one you are describing, with the sole exception of the firmware in question being temporarily transported in the kernel binary and uploaded in the device. No, to get the same case you have to read out the bios/flash and include that in Debian to be distributed by debian in main. If you do that the hardware vendor would sue you in a minute for copyright infringement because you don't even have distribution rights. Notice that i am not arguing that the firmware is not non-free and doesn't break the DSFG, but that the firmware is not a derived work of the linux kernel, just aggregated on the same distribution media (the linux binary file), i think you are seriously confusing the two in your above argumentation. The first makes the firmware unfit to be in main, while the second is a GPL violation of the kernel source, and forbids all distribution of it. Finally, what you mention is more akin to the unicorn driver, which is a driver for a soft-ADSL pci modem, which links to a non-free, binary-only, x86-only ADSL library. This is indeed more than just agregation, and after i engaged bewan over it, and we consulted with RMS and the FSF, they released their drivers with a GPL+exception licence, and the package is now happily sitting in non-free, waiting for someone to write a free ADSL library replacement. Indeed. That was one of the bad examples. Indeed. It is non-free, and the problematicness of the licencing has been solved. It is an out-of-tree module though, so not something to worry about in this case. The non-free library never runs in the same address space as the rest of the program. Does that mean this is just an aggregation of works and GPL compliant? I am not familiar enough with how library are run, but there is some very different way in which libraries called by programs work, and the way the main cpu interacts with a peripheral processor on a pci card, don't you think ? Or do you want also to declare that you can run GPLed Linux kernels only on hardware whose VHDL of every chip on it as well as schematics and gerbers are freely available, not counting that you would also need free PCB design tools which can read the format, as well as free tools running the manufacturing plant, and so on ... _IF_ Debian would distribute the CPU in main then zes, I would require that. But Debian is not a hardware vendor. Ah, again you are confused. We are not discussing the DFSG-freeness, but the violation of the GPL of the kernel here. Two totally separate matters, please read the debian-legal argumentation of last year about this issue in order to clarify your comprehension of this issue. Where people buy their hardware or how free their hardware is has little to do with Debian main. It is a problem for the linux upostream authors to support the hardware with free source code and sometimes they fail. Indeed. but when you mention GPL violation, it means that you are not allowed to distribute the whole linux kernel, even in non-free. multiarch. I have a hacked together cdebootstrap that first concatenates the Packages files from multiple sources and then calls libd-i. It is ugly but it works. This workaround is quite simple to copy into D-I if you really
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
Nathanael Nerode [EMAIL PROTECTED] writes: The point of my initial message was not to argue: it was that the etch timeline is unrealistic, because I see no progress on removing the substantial number of sourceless binaries from the Linux kernel source package, and it's *after* the kernel was supposed to have frozen! Please don't lose track of the fact that there's nothing inherently wrong with a sourceless binary if that's all the source anyone *has*. If the assembly was painstakingly reverse-engineered, it *is* the source for all intents and purposes, and no license requires that the author supply something which doesn't actually exist. This of course doesn't apply to binary blobs given to us by people who generated them from some source they're not releasing, of course. I don't know how many of the files you're talking about may fall into this category, but this distinction seems to be lost in this thread and I don't want people to miss it. It *does* happen that the concept of source isn't overly meaningful for some things. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On Thu, Aug 10, 2006 at 04:50:29PM +0200, Goswin von Brederlow wrote: Sven Luther [EMAIL PROTECTED] writes: On Thu, Aug 10, 2006 at 03:51:31PM +0200, Goswin von Brederlow wrote: Sven Luther [EMAIL PROTECTED] writes: Which would be a task for the debian-cd team. Has anyone talk to them about it? Currently there is no infrastructure to build non-free d-i images. doing non-free cds would be rather easy, and it is something i can do myself, as i still have svn access to the debian-cd project. Friendly, Sven Luther There we go. Something constructive for you to do that you are intrested in anyway. I am interested in lot of stuff, but the point we are trying to make, is that the kernel team has not the ressources to handle this as it should, so we either keep the status quo, or get some outside help. Of all those complaining about the non-free modules, and asking why we have not fixed it yet, almost nobody has come up and actually proposed help, just, as you did, propose we somehow find more free time to work on it. So, i have given a few hints on how even kernel team outsiders with no kernel coding experience can start to give a hand on this. Nobody replied to that call for help yet, the ball is in your camp. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
Sven Luther [EMAIL PROTECTED] writes: On Thu, Aug 10, 2006 at 04:32:52PM +0200, Goswin von Brederlow wrote: Sven Luther [EMAIL PROTECTED] writes: I am not familiar enough with how library are run, but there is some very different way in which libraries called by programs work, and the way the main cpu interacts with a peripheral processor on a pci card, don't you think ? Or do you want also to declare that you can run GPLed Linux kernels only on hardware whose VHDL of every chip on it as well as schematics and gerbers are freely available, not counting that you would also need free PCB design tools which can read the format, as well as free tools running the manufacturing plant, and so on ... _IF_ Debian would distribute the CPU in main then zes, I would require that. But Debian is not a hardware vendor. Ah, again you are confused. We are not discussing the DFSG-freeness, but the violation of the GPL of the kernel here. Two totally separate matters, please read the debian-legal argumentation of last year about this issue in order to clarify your comprehension of this issue. You misread me. Debian is NOT distributing hardware. Therefore any license of software included with the hardware is totaly irelevant to Debian. If you want to buy only free hardware that is your problem and we are all sorry that you won't be able to so. But it is not a problem with the SC or DFSG that you can't. Hardware is also not included in any GPL software including the linux kernel. Your hardware is not free argument is totaly besides the issue. That is what I ment. Where people buy their hardware or how free their hardware is has little to do with Debian main. It is a problem for the linux upostream authors to support the hardware with free source code and sometimes they fail. Indeed. but when you mention GPL violation, it means that you are not allowed to distribute the whole linux kernel, even in non-free. Hence the need to fix them. multiarch. I have a hacked together cdebootstrap that first concatenates the Packages files from multiple sources and then calls libd-i. It is ugly but it works. This workaround is quite simple to copy into D-I if you really want to work on it. Ah, nice, i would really be interested in that. Now, the problem is that it needs to be integrated into the main d-i work, and given their over-conservativeness and immobilism, it is way too late for etch, or didn't you hear that d-i was supposed to be frozen this week ? Please stop making this into an attack. Better spend that energy into Why ? i am only stating facts, and they banned me of the d-i team for daring toeven mention some of the d-i fallacies like this one. They are not facts but your opinion. What you call over-conservativeness and immobilism others call carefullness and stability. You might even be right but you are not helping the issue nor yourself. We all know by now that you were kicked out, you don't have to repeat it. When you take the firmware out of the hardware and into debian / the kernel then it can become an issue, not before. writing a patch. You've done D-I work before so maybe you even looked at libd-i source before. I do have, but that is beside the point. Nope, i keep pointing out the responsabilities of the current mess to where it belongs. I don't care about the d-i guys, the DPL clearly said i should expect nothing of them (well, of a few of them), and fork d-i, so ... But finger pointing will get no work done. Just annoy people. It will not allow anyone to forget the issue and believe that everything is fine, indeed. So you will keep the (rightious or wrongfull doesn't matter) hate against you alive and bruning brightly. Do you believe that will help your cause? (and no, don't answere that) If the kernel is split up then D-I not handling non-free will be a release blocker and will be solved. I don't think compromising ideals because D-I doesn't yet handle non-free is the right thing to do. It is not like implementing this will take more than a weekend. Maybe, but without me stepping up, and pointing the finger to this problem, nobody would have cared, probably they would have been afraid to suffer the same treatement i got at their hands for daring mention those problems. You are not stepping up. So far you are just pointing fingers. And so far I haven't seen anybody care that didn't care already. I am forbidden to do kernel/d-i related work by Frans who threatened me on irc about it. You can always write patches and send them to the BTS. If you fear retribution by Frans then go that way and get a fellow kernel team member to commit the changes. I feel for you and know that that is awkward but that is how it is currently. If your desire to help is greater than the obstacles then stick with it. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On Thu, Aug 10, 2006 at 06:14:08PM +0200, Goswin von Brederlow wrote: Sven Luther [EMAIL PROTECTED] writes: Where people buy their hardware or how free their hardware is has little to do with Debian main. It is a problem for the linux upostream authors to support the hardware with free source code and sometimes they fail. Indeed. but when you mention GPL violation, it means that you are not allowed to distribute the whole linux kernel, even in non-free. Hence the need to fix them. Indeed, and this was done for tg3/broadcom, and the qlsomething ones. Those files are now correctly licenced, but are still non-free, and it is this second issue that we are discussing here. multiarch. I have a hacked together cdebootstrap that first concatenates the Packages files from multiple sources and then calls libd-i. It is ugly but it works. This workaround is quite simple to copy into D-I if you really want to work on it. Ah, nice, i would really be interested in that. Now, the problem is that it needs to be integrated into the main d-i work, and given their over-conservativeness and immobilism, it is way too late for etch, or didn't you hear that d-i was supposed to be frozen this week ? Please stop making this into an attack. Better spend that energy into Why ? i am only stating facts, and they banned me of the d-i team for daring toeven mention some of the d-i fallacies like this one. They are not facts but your opinion. What you call over-conservativeness and immobilism others call carefullness and stability. You might even be right but you are not helping the issue nor yourself. We all know by now that you were kicked out, you don't have to repeat it. Indeed, so everyone can conveniently forget it, right. When you take the firmware out of the hardware and into debian / the kernel then it can become an issue, not before. There are two issues, and you are confusing both of them and using arguments for the one in defense of the other. writing a patch. You've done D-I work before so maybe you even looked at libd-i source before. I do have, but that is beside the point. Nope, i keep pointing out the responsabilities of the current mess to where it belongs. I don't care about the d-i guys, the DPL clearly said i should expect nothing of them (well, of a few of them), and fork d-i, so ... But finger pointing will get no work done. Just annoy people. It will not allow anyone to forget the issue and believe that everything is fine, indeed. So you will keep the (rightious or wrongfull doesn't matter) hate against you alive and bruning brightly. Do you believe that will help your cause? (and no, don't answere that) Nothing will help my cause. And seriously, i couldn't care less about people who hate me because i wrote a couple of mails, and then indulge in exactly the same thing later on. If the kernel is split up then D-I not handling non-free will be a release blocker and will be solved. I don't think compromising ideals because D-I doesn't yet handle non-free is the right thing to do. It is not like implementing this will take more than a weekend. Maybe, but without me stepping up, and pointing the finger to this problem, nobody would have cared, probably they would have been afraid to suffer the same treatement i got at their hands for daring mention those problems. You are not stepping up. So far you are just pointing fingers. And so far I haven't seen anybody care that didn't care already. I am forbidden to do kernel/d-i related work by Frans who threatened me on irc about it. You can always write patches and send them to the BTS. If you fear retribution by Frans then go that way and get a fellow kernel team member to commit the changes. I feel for you and know that that is awkward but that is how it is currently. If your desire to help is greater than the obstacles then stick with it. I will only go this way so far, but someday, i will fork d-i, and declare them obsolet, and do my stuff as i see fit, and let them the hurdle to catch up if they like. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
Russ Allbery [EMAIL PROTECTED] writes: Please don't lose track of the fact that there's nothing inherently wrong with a sourceless binary if that's all the source anyone *has*. I think in most of the cases under consideration, we have firmware which a hardware manufacturer wrote and then either published or stuck inside a windows driver, and which then found its way into a Linux driver. So while your statement is right, the relevant anyone includes the hardware manufacturer, who quite likely does have source in a more convenient form than a pure binary. If the assembly was painstakingly reverse-engineered, it *is* the source for all intents and purposes [...] Quite right, but assembly code is *not* binary. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On Tue, Aug 08, 2006 at 04:49:33PM -0700, Thomas Bushnell BSG wrote: Sven Luther [EMAIL PROTECTED] writes: Well, it reads to me that we won't screw our users without second thought like some here are proposing. In my opinion, we have been screwing our users for years by lying to them about whether their software was free. We would even say things like hardware such-and-such is supportable with free software and then ship them a non-free driver. Well, its a different sort of screwing. But then my position on this has always been to be clear, and say things plainly as they are, and not like others or other distribs or upstream to ignore the issue and hope it does go away. At this point we have those possible choices : 1) move the kernel to non-free, and be done with it. 2) either move the individual affected drivers or just their firmware if possible to non-free, and keep the cripled kernel in main. 3) reverse-engineer and reimplement those firmwares, or convince upstream to free them. 4) pass a GR explaining the issue as is, and admitting our incapacity to fix it with 2 or 3 due to lack of ressources. 3) would be nicest, but it is a never ending task, and we can't do it. We could do 2), but even this will mean some serious work and possibly a delay of the etch release schedule, especially as we don't have a full audit of what files are exactly affected. 2) (and 1) also mean the cooperation of the d-i team, which we have not been getting on this so far, all to the contrary, since they need to fix d-i to load more than one apt source, and since the d-i folk probably consider the etch d-i as frozen right now, ... So, this leaves us what, as reasonable solution for etch ? 1 and 4, and 1 will be too disruptive, so only 4 is left. It is not as if the issue is new though, we have been knowing about this since almost a year, and many voiced their concern or support at various time, but actual help was few and far between (partly our fault in one case though at least). Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On Tue, Aug 08, 2006 at 08:12:48PM -0400, Jim Crilly wrote: On 08/08/06 04:49:33PM -0700, Thomas Bushnell BSG wrote: Sven Luther [EMAIL PROTECTED] writes: Well, it reads to me that we won't screw our users without second thought like some here are proposing. In my opinion, we have been screwing our users for years by lying to them about whether their software was free. We would even say things like hardware such-and-such is supportable with free software and then ship them a non-free driver. I'm sure this has been suggested/covered before, but what's wrong with just sticking those drivers in non-free and giving the user a choice during Well, i mentioned this already elsewhere in this thread, but there you go : 1) it is lot of work, and we (the kernel team) don't realy have the ressources for it. 2) there is currently no exhaustive list of affected drivers, there may even be some case of things like main processor micro-code affected. 3) it demands works of part of debian outside the kernel team, particularly the d-i and eventually archive folk. The d-i have not been cooperative to this idea, and even mentioning it to them has resulted in a barrage of agresive bashing. But then maybe it was just because they don't like me and i dared to mention this all those months back. In any case, they have not fixed their side of it, and there appears to be no plan to do so, i was kicked out of the d-i project, and Frans threatened me if i even dared work on kernel/d-i based issues. installation? Sure, it'll screw the users that won't have Internet access during the installation, but as long as it's possible to make custom installation discs that'll probably take care of itself. You can do a CD media which includes the non-free modules, you would have to build a non-free d-i image set anyway. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
Sven Luther [EMAIL PROTECTED] writes: 2) either move the individual affected drivers or just their firmware if possible to non-free, and keep the cripled kernel in main. This is certainly the last resort, in my opinion, but it isn't crippled. Merely not supporting particular pieces of hardware, in a world in which Linux *already* fails to support lots of popular hardware, is not a disaster. It's a shame, and we should avoid it if we can, but it's a shame. 3) would be nicest, but it is a never ending task, and we can't do it. We could do 2), but even this will mean some serious work and possibly a delay of the etch release schedule, especially as we don't have a full audit of what files are exactly affected. Life is rough. The kernel team has had *ample* warning, since it was midway through *sarge* that the rules became clear. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
Sven Luther [EMAIL PROTECTED] writes: 4) pass a GR explaining the issue as is, and admitting our incapacity to fix it with 2 or 3 due to lack of ressources. We do not need a GR to simply follow our existing procedures. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On Wed, Aug 09, 2006 at 12:57:36AM -0700, Thomas Bushnell BSG wrote: Sven Luther [EMAIL PROTECTED] writes: 2) either move the individual affected drivers or just their firmware if possible to non-free, and keep the cripled kernel in main. This is certainly the last resort, in my opinion, but it isn't crippled. Merely not supporting particular pieces of hardware, in a world in which Linux *already* fails to support lots of popular hardware, is not a disaster. It's a shame, and we should avoid it if we can, but it's a shame. 3) would be nicest, but it is a never ending task, and we can't do it. We could do 2), but even this will mean some serious work and possibly a delay of the etch release schedule, especially as we don't have a full audit of what files are exactly affected. Life is rough. The kernel team has had *ample* warning, since it was midway through *sarge* that the rules became clear. Nope, the issue only surfaced early after the sarge release, a bit less than a year ago, when the new kernel team formed. Now, this is a long term *UPSTREAM* kind of work, and we simply don't have the ressources of undertaking it. As for me, i have been bogged down into defending against the multiple tentatives to get ride of me since early marsh, and could thus produce no useful work of this nature during this time, Andres Salomon left because his tentative of exclusion of me from debian failed, others have been assortedly busy too. And it is not as if *YOU* had not ample warning about the ressource problems, since we mentioned the lack of manpower and ressources regularly since a almost as long as the issue surfaced. And this is not really a work which can be done without diverting ressources from normal maintenance work, which would be detrimental. So, basically, you are criticizing the kernel team for not having devoted enough of their *volunteer* time to this issue, and at the same time you expect us to provide good quality kernel packages to debian ? Well, again, the offer is open, and i already multiple times proposed those like you to start helping and providing an exhaustive list of those files which are involved, as well as a basic classification of the nature of their problem. This is assuredly within the reach of each debian maintainer or associated, and doesn't need any particular kernel-coding skill, but some legal/licencing knowledge. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On Wed, Aug 09, 2006 at 12:58:33AM -0700, Thomas Bushnell BSG wrote: Sven Luther [EMAIL PROTECTED] writes: 4) pass a GR explaining the issue as is, and admitting our incapacity to fix it with 2 or 3 due to lack of ressources. We do not need a GR to simply follow our existing procedures. Sure, we do, because wehad a pre-sarge GR, which allowed to ignore the firmware (and other issues), but only for the sarge release, remember ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
Sven Luther [EMAIL PROTECTED] writes: Nope, the issue only surfaced early after the sarge release, a bit less than a year ago, when the new kernel team formed. It was discussed *before* sarge was released that there was non-free firmware in the kernel, and we decided to ignore it for the sarge release. We explicitly did *not* decide to ignore it forever. So, basically, you are criticizing the kernel team for not having devoted enough of their *volunteer* time to this issue, and at the same time you expect us to provide good quality kernel packages to debian ? No. I would be content with a we don't support that hardware decision, though it would be less than the best thing. I'm willing to wait for this work to be finished before etch is released. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
Sven Luther [EMAIL PROTECTED] writes: On Wed, Aug 09, 2006 at 12:58:33AM -0700, Thomas Bushnell BSG wrote: Sven Luther [EMAIL PROTECTED] writes: 4) pass a GR explaining the issue as is, and admitting our incapacity to fix it with 2 or 3 due to lack of ressources. We do not need a GR to simply follow our existing procedures. Sure, we do, because wehad a pre-sarge GR, which allowed to ignore the firmware (and other issues), but only for the sarge release, remember ? We can simply take our time to do (2). It is the job of a package maintainer to check the licenses of their software; if the kernel team cannot do so by December, even with help, I don't mind waiting. However, what started this thread IIRC was a complaint that the kernel team was *closing* the relevant bugs. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On Wed, Aug 09, 2006 at 02:02:42AM -0700, Thomas Bushnell BSG wrote: Sven Luther [EMAIL PROTECTED] writes: On Wed, Aug 09, 2006 at 12:58:33AM -0700, Thomas Bushnell BSG wrote: Sven Luther [EMAIL PROTECTED] writes: 4) pass a GR explaining the issue as is, and admitting our incapacity to fix it with 2 or 3 due to lack of ressources. We do not need a GR to simply follow our existing procedures. Sure, we do, because wehad a pre-sarge GR, which allowed to ignore the firmware (and other issues), but only for the sarge release, remember ? We can simply take our time to do (2). It is the job of a package maintainer to check the licenses of their software; if the kernel team cannot do so by December, even with help, I don't mind waiting. Well, the question is if we can release etch in this state or not. Given the previous GR wording, this is not the case, and we either delay etch for a long time, or provide an override. However, what started this thread IIRC was a complaint that the kernel team was *closing* the relevant bugs. Well, i may not have followed the start of it, but it is something that both the RM team as the kernel team are aware of, even if some individual members may prefer to keep the status quo or ignore the issue. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On Wed, Aug 09, 2006 at 02:01:33AM -0700, Thomas Bushnell BSG wrote: Sven Luther [EMAIL PROTECTED] writes: Nope, the issue only surfaced early after the sarge release, a bit less than a year ago, when the new kernel team formed. It was discussed *before* sarge was released that there was non-free firmware in the kernel, and we decided to ignore it for the sarge release. We explicitly did *not* decide to ignore it forever. Maybe, but the kernel team was really operational, and not saddled with broken legacy packaging only after the sarge release. So, basically, you are criticizing the kernel team for not having devoted enough of their *volunteer* time to this issue, and at the same time you expect us to provide good quality kernel packages to debian ? No. I would be content with a we don't support that hardware decision, though it would be less than the best thing. I'm willing to wait for this work to be finished before etch is released. Yep, but the question is, are the rest of the DDs willing to wait too ? This is best answered by a GR, not sure if it needs 3:1 supermajority or not, i think if it is only a delay-it-once-more, it does not need that, contrary to a changing of the wording of the social contract would be. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
Hallo, On Wed, Aug 09, 2006 at 02:02:42AM -0700, Thomas Bushnell BSG wrote: We can simply take our time to do (2). It is the job of a package maintainer to check the licenses of their software; if the kernel team cannot do so by December, even with help, I don't mind waiting. then, please, send patches. Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On 08/02/06 22:17, Nathanael Nerode wrote: Start with drivers/char/drm/mga_ucode.h. This is distributable, because it's under a BSD license, but it's not free software, because there's no source code. There is no source code, because there never was any source code. What do you think should be done if source code doesn't make sense or can't be made? Jeff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
[EMAIL PROTECTED] wrote: On 08/02/06 22:17, Nathanael Nerode wrote: Start with drivers/char/drm/mga_ucode.h. This is distributable, because it's under a BSD license, but it's not free software, because there's no source code. There is no source code, because there never was any source code. Do you have *actual evidence* of this? Are you a Matrox employee? Do you have an email from one? Do you know the microcode format and can you explain how to easily edit the hex to make the microcode do different things? If any of the above, please provide your evidence. If the microcode was wriiten in hex, hex is the sorurce code and we can include it. Otherwise, I contend that you are just making this up and Matrox actually has source code which it is withholding. Replies to debian-kernel please. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
I apologize for responding to Marco's post; in retrospect he was clearly trolling and I should not have responded to him. The point of my initial message was not to argue: it was that the etch timeline is unrealistic, because I see no progress on removing the substantial number of sourceless binaries from the Linux kernel source package, and it's *after* the kernel was supposed to have frozen! Is there a plan for dealing with this fast enough to avoid delaying the release of etch? If so, please post it. If not, I suggest the following process improvements: For each driver containing a sourceless binary, someone (probably me) will file a single bug against the source package linux-2.6. Currently there is a single bug (242866/243022) covering multiple issues, against 'kernel', which is a pseudo-package. Looking at the list of antique bugs against 'kernel', I don't think anyone is reading them. Also, with the planned removal of pre-2.6 kernel packages, a bug against linux-2.6 seems sufficient to cover everything. Why one bug per driver? Because each driver's bug is slightly different and I expect each to be fixed in a slightly different way. Some bugs are distributability issues, while some are clearly distributable and simply non-free. Some may be fixed by a new upstream version. Some may be fixed by implementing firmware loading and a non-free firmware package; some may be fixed by moving the driver to an out-of-tree kernel module; others may be fixed by removing the driver entirely; others (where the firmware is unimportant) may be fixed by removing the firmware and the support for whatever feature it enables. In the case of the DRM modules, the result may depend on the implementation of features in X, and bugs may block on that. The point is that each case is going to be different. The progress on the different drivers is already different. This should make tracking the issues significantly clearer: specifically it will make it clear exactly what needs to be done to fix this. It would also make it look a bit less like an infinite tentacled monster, perhaps making it easier for people to bite off one bug at a time. (Certainly I get confused posting fixes for different drivers to the same bug.) We would then convert 242866 to a meta-bug blocking on each individual bug. How does that sound? http://wiki.debian.org/KernelFirmwareLicensing is grossly out-of-date, but I will integrate the relevant information from that in the process. Alternative option: the Wiki page could be revived and used to coordinate the process. Unfortunately it's quite out-of-date, and it's unwieldly. I prefer the BTS option because it's more permanent, harder to ignore, and better at holding patches and whatnot. -- Nathanael Nerode [EMAIL PROTECTED] Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On Tue, Aug 08, 2006 at 07:39:21AM +0200, Mike Hommey wrote: On Tue, Aug 08, 2006 at 06:49:32AM +0200, Sven Luther [EMAIL PROTECTED] wrote: On Mon, Aug 07, 2006 at 04:46:09PM -0700, Thomas Bushnell BSG wrote: [EMAIL PROTECTED] (Marco d'Itri) writes: On Aug 08, Thomas Bushnell BSG [EMAIL PROTECTED] wrote: We Do Not Distribute Non-Free Software No Matter How Much It Helps Our Users. Now think about why we do not do it. It does not matter. Different members of Debian have different reasons. We have all agreed to work together on the basis of the Social Contract, which says that We Do Not Distribute Non-Free Software No Matter How Much It Helps Our Users. # Our priorities are our users and free software We will be guided by the needs of our users and the free software community. We will place their interests first in our priorities. We will support the needs of our users for operation in many different kinds of computing environments. We will not object to non-free works that are intended to be used on Debian systems, or attempt to charge a fee to people who create or use such works. We will allow others to create distributions containing both the Debian system and other works, without any fee from us. In furtherance of these goals, we will provide an integrated system of high-quality materials with no legal restrictions that would prevent such uses of the system. Where do you read we allow ourselves to distribute non-free software for user convenience ? Well, it reads to me that we won't screw our users without second thought like some here are proposing. But then, i repeat, everyone is very welcome to participate in solving this the nice way, and i am highly impatient to see the extensive listings you and others may produce, and then some plan on how to go forward from there. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
Sven Luther [EMAIL PROTECTED] writes: # Our priorities are our users and free software We will be guided by the needs of our users and the free software community. We will place their interests first in our priorities. We will support the needs of our users for operation in many different kinds of computing environments. We will not object to non-free works that are intended to be used on Debian systems, or attempt to charge a fee to people who create or use such works. We will allow others to create distributions containing both the Debian system and other works, without any fee from us. In furtherance of these goals, we will provide an integrated system of high-quality materials with no legal restrictions that would prevent such uses of the system. Nothing here says that when we have no way to support a user's task with free software, we will go ahead and ship nonfree software to do this. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
Sven Luther [EMAIL PROTECTED] writes: Well, it reads to me that we won't screw our users without second thought like some here are proposing. In my opinion, we have been screwing our users for years by lying to them about whether their software was free. We would even say things like hardware such-and-such is supportable with free software and then ship them a non-free driver. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On 08/08/06 04:49:33PM -0700, Thomas Bushnell BSG wrote: Sven Luther [EMAIL PROTECTED] writes: Well, it reads to me that we won't screw our users without second thought like some here are proposing. In my opinion, we have been screwing our users for years by lying to them about whether their software was free. We would even say things like hardware such-and-such is supportable with free software and then ship them a non-free driver. I'm sure this has been suggested/covered before, but what's wrong with just sticking those drivers in non-free and giving the user a choice during installation? Sure, it'll screw the users that won't have Internet access during the installation, but as long as it's possible to make custom installation discs that'll probably take care of itself. Jim. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On Sun, Aug 06, 2006 at 04:50:54PM -0700, Thomas Bushnell BSG wrote: Sven Luther [EMAIL PROTECTED] writes: So, i don't believe there is much choice left to the kernel team in this issue but to ask for a waiver of the DFSG compliance for the kernel for etch, and hope the d-i folk take their responsabilities a bit more seriously for the etch+1 release. Or, the kernel team could actually comply with the DFSG for the first time ever. These are fine words, but how do you think they can translate into reality ? We don't currently have the ressources to do it the way it should be done, and evne if we did, the deficiencies of d-i will make the work we do useless. But then, you could help, and put your actions where your mouth is, by helping in the elaboration of an exhaustive list of such problematic firmware hexdumps, together with their licencing conditions, their copyright holder, and a summary of what the module is good for. This stands for anyone having a similar discourse to yours too :) Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
Hello, On Mon, Aug 07, 2006 at 09:32:11AM +0200, Sven Luther wrote: These are fine words, but how do you think they can translate into reality ? We don't currently have the ressources to do it the way it should be done, and evne if we did, the deficiencies of d-i will make the work we do useless. Sven, can you please finally STOP flaming against the debian-installer team, thank you. But then, you could help, and put your actions where your mouth is, by helping in the elaboration of an exhaustive list of such problematic firmware hexdumps, together with their licencing conditions, their copyright holder, and a summary of what the module is good for. I agree, everyone who wants to see the firmware issue solved should either start doing something about it or be silent. here is an outdated wiki document, where to start with: http://wiki.debian.org/KernelFirmwareLicensing Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On Mon, Aug 07, 2006 at 10:23:31AM +0200, Frederik Schueler wrote: Hello, On Mon, Aug 07, 2006 at 09:32:11AM +0200, Sven Luther wrote: These are fine words, but how do you think they can translate into reality ? We don't currently have the ressources to do it the way it should be done, and evne if we did, the deficiencies of d-i will make the work we do useless. Sven, can you please finally STOP flaming against the debian-installer team, thank you. Well, its a simple statement of facts, is it not ? I mean, did you find any untruth in what i said above, or in the other mail ? It has a direct bearing over the problem at hand, and a certain subset of the d-i folk exhibited inacceptable behaviour against me over it, so it is only just that their errors and inadequacies are remembered when we speak about these topics, since it was me trying to speak about those topics wich pushed them in the first place to start the witch hunt against me, and nothing i can do can in any way change the current mess, even the DPL in his attempted second mediation came to the conclusion that i should just fork d-i or something. So, no, i will not stop this, and i will never forget what they did to me, nor the circunstances in which they did it, i tried mutliple times, but it was rejected out of hand, so ... But then, you could help, and put your actions where your mouth is, by helping in the elaboration of an exhaustive list of such problematic firmware hexdumps, together with their licencing conditions, their copyright holder, and a summary of what the module is good for. I agree, everyone who wants to see the firmware issue solved should either start doing something about it or be silent. here is an outdated wiki document, where to start with: http://wiki.debian.org/KernelFirmwareLicensing Thanks for the hint. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
Sven Luther [EMAIL PROTECTED] writes: On Sun, Aug 06, 2006 at 01:21:32PM +0200, Goswin von Brederlow wrote: [EMAIL PROTECTED] (Marco d'Itri) writes: On Aug 04, Goswin von Brederlow [EMAIL PROTECTED] wrote: think not? Prove it by proposing a GR. More importantly, the release team I had such a plan, but no time to implement it currently. How do you handle the fact that it is a license violation making the thing illegal to distribute? I see that the lawyers of SuSE and Red Hat do not believe this to be true or at least do not consider it a problem, and this is enough for me to ignore the opinion of the debian-legal@ armchair lawyers. -- ciao, Marco I hope you do believe this to be true. Otherwise you would need to go back to NM and do the licensing section again. There can be no doubt that binaries without source or even a DO NOT DISTRIBUTE notice break the GPL. No, because those are not linked together with the GPLed code, but are a mere aggregation of works inside the same media, i.e. the binary file. Those non-free firmware will never run inside the same memory space as the kernel, and are offloaded to a peripheral processor, and the communication media between the kernel and this peripheral processor running said firmware is clearly defined, there is no doubt that those non-free firmware do not break the kernel GPL. They are linked in, they have symbols, the code directly references their address. Can you name one tool that will easily remove such aggregated code from the kernel image? And we aren't just talking about firmware here. There are header files and even C source files with issues in the vanilla kernel. I agree with you that firmware included in a kernel deb that gets loaded with the firmware loader just an aggregation. But that is not the issue here. And even for an aggregation of works the DFSG holds and you are still in trouble. Let me make another example. I take a GPL program and link in a non-free library plus glue code that forks a child and uses the library. Only the child does use the non-free library and the communication between father and child is clearly defined. The non-free library never runs in the same address space as the rest of the program. Does that mean this is just an aggregation of works and GPL compliant? If I put the non-free library into an external plugin and (optionaly) dlopen it then I have a completly different story. The second case is easier, we have simply to remove the non-free firmware, and put it in non-free, and/or remove completely the non-free driver and put it in non-free. In the case of modules vital to boot the machine we are trully screwed here, and by some of ourselves even. The problem is that the installer people, who where told repeteadly by me and others about this issue since over 6 month, and should have worked on enabling the installer to load .udebs from multiple apt/anna sources and not just one, thus enabling to place those non-free .udebs into a separate non-free .udeb archive, and solve this problem neatly. I've been bugging Bastian about this issue as well since I need this for multiarch. I have a hacked together cdebootstrap that first concatenates the Packages files from multiple sources and then calls libd-i. It is ugly but it works. This workaround is quite simple to copy into D-I if you really want to work on it. But then, the d-i team, has prefered to ignore this issue, shot the messenger, and go into kicking out, witch hunts and diffamatory tactics in order to not face their own lack of vision and inadequateness, in the same way as their reaction to the kernel module .udeb proposal was over-agressive and now leaves us in mostly the same situation as we where at the sarge release time, with the d-i team incapacity to handle kernel abi bumps and security upgrades in a timely fashion. One problem is that you keep banging on the door, where the watchdog barks at you and the armed guards won't let you in. Try the window or the backdoor. Change your approach. Personaly I think the only way to get D-I to use non-free udebs is to first have some. Preferably something essential. The harddisk driver or network driver of Bastians or Joeys system would be perfect. Since we can't convince the developer to implement this feature for its own merit lets create some desperate need for it. So, i don't believe there is much choice left to the kernel team in this issue but to ask for a waiver of the DFSG compliance for the kernel for etch, and hope the d-i folk take their responsabilities a bit more seriously for the etch+1 release. If the kernel is split up then D-I not handling non-free will be a release blocker and will be solved. I don't think compromising ideals because D-I doesn't yet handle non-free is the right thing to do. It is not like implementing this will take more than a weekend. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On Aug 07, Goswin von Brederlow [EMAIL PROTECTED] wrote: No, because those are not linked together with the GPLed code, but are a mere aggregation of works inside the same media, i.e. the binary file. Those non-free firmware will never run inside the same memory space as the kernel, and are offloaded to a peripheral processor, and the communication media between the kernel and this peripheral processor running said firmware is clearly defined, there is no doubt that those non-free firmware do not break the kernel GPL. They are linked in, they have symbols, the code directly references their address. Can you name one tool that will easily remove such No. They are a char array, it's data copied where the hardware wants it. It's not code called by other functions. aggregated code from the kernel image? Not relevant. -- ciao, Marco signature.asc Description: Digital signature
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On Mon, Aug 07, 2006 at 02:48:08PM +0200, Goswin von Brederlow wrote: Sven Luther [EMAIL PROTECTED] writes: On Sun, Aug 06, 2006 at 01:21:32PM +0200, Goswin von Brederlow wrote: [EMAIL PROTECTED] (Marco d'Itri) writes: On Aug 04, Goswin von Brederlow [EMAIL PROTECTED] wrote: think not? Prove it by proposing a GR. More importantly, the release team I had such a plan, but no time to implement it currently. How do you handle the fact that it is a license violation making the thing illegal to distribute? I see that the lawyers of SuSE and Red Hat do not believe this to be true or at least do not consider it a problem, and this is enough for me to ignore the opinion of the debian-legal@ armchair lawyers. -- ciao, Marco I hope you do believe this to be true. Otherwise you would need to go back to NM and do the licensing section again. There can be no doubt that binaries without source or even a DO NOT DISTRIBUTE notice break the GPL. No, because those are not linked together with the GPLed code, but are a mere aggregation of works inside the same media, i.e. the binary file. Those non-free firmware will never run inside the same memory space as the kernel, and are offloaded to a peripheral processor, and the communication media between the kernel and this peripheral processor running said firmware is clearly defined, there is no doubt that those non-free firmware do not break the kernel GPL. They are linked in, they have symbols, the code directly references their address. Can you name one tool that will easily remove such i guess objdump would do it, from most of these cases, the only symbol involved is the position of it in the code, and the incrimated code is just a binary hexdump contained in a single variable + size. aggregated code from the kernel image? And we aren't just talking about firmware here. There are header files and even C source files with issues in the vanilla kernel. Well, we are speaking about firmware hexdumps, i don't know about the others you are referencing, but if there are other suchs, please list them explicitly. And no, a separate header file containing just this single variable doesn't count. I agree with you that firmware included in a kernel deb that gets loaded with the firmware loader just an aggregation. But that is not the issue here. What is then ? And even for an aggregation of works the DFSG holds and you are still in trouble. Sure, the DFSG says that we need the source code for those, and they are thus non-free, but what i am arguing is that they are not violation of the kernel GPL, since they are separate aggregate works. Let me make another example. I take a GPL program and link in a non-free library plus glue code that forks a child and uses the library. Only the child does use the non-free library and the communication between father and child is clearly defined. Let me make another example. You buy a random bunch of hardware, and either run linux on it, or run a free linux driver running it. This hardware in question happens to have some random bios on it, which is non-free, or some fpga config file hidden in a flash. This is exactly the same case as the one you are describing, with the sole exception of the firmware in question being temporarily transported in the kernel binary and uploaded in the device. If you follow the FSF FAQ about the GPL, you will see that there are a certain amount of criterias which apply here, among them the separate memory pool/area one, as well as the well defined communication interface, which is clearly respected here. So, altough IANAL, i believe without doubts that we are not seing a GPL violation here, and that the non-free firmware and the linux kernel are mere aggregation. After writing this to LKML last year, i also contacted the FSF legal counsel, and altough they didn't give a supportive analysis of this, there was no strong outcry either. Not sure what this means. I believe i got the consensus of debian-legal behind me on this one, as you would see if you consulted the archives, and the broadcom, and QL-something, legal team, also found this analysis reasonable and changed their tg3 and ql-something licencing accordyingly. Also, if you really want to argue the other way, you will end up in a world of trouble, and will end not being able to run linux on any box around i know. Finally, what you mention is more akin to the unicorn driver, which is a driver for a soft-ADSL pci modem, which links to a non-free, binary-only, x86-only ADSL library. This is indeed more than just agregation, and after i engaged bewan over it, and we consulted with RMS and the FSF, they released their drivers with a GPL+exception licence, and the package is now happily sitting in non-free, waiting for someone to write a free ADSL library replacement. The non-free library never runs in the same address space as the rest of the
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On Mon, Aug 07, 2006 at 04:53:51PM +0200, Marco d'Itri wrote: On Aug 07, Goswin von Brederlow [EMAIL PROTECTED] wrote: No, because those are not linked together with the GPLed code, but are a mere aggregation of works inside the same media, i.e. the binary file. Those non-free firmware will never run inside the same memory space as the kernel, and are offloaded to a peripheral processor, and the communication media between the kernel and this peripheral processor running said firmware is clearly defined, there is no doubt that those non-free firmware do not break the kernel GPL. They are linked in, they have symbols, the code directly references their address. Can you name one tool that will easily remove such No. They are a char array, it's data copied where the hardware wants it. It's not code called by other functions. Yeah, exact, its mips or arm machine code, uploaded to the embedded core in the chip used for the peripheral in question. Err, you probably have a very different definition of code than me, or maybe you have absolutely no clue about how hardware works, which is sincerely doubt. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
Sven Luther wrote: On Mon, Aug 07, 2006 at 04:53:51PM +0200, Marco d'Itri wrote: On Aug 07, Goswin von Brederlow [EMAIL PROTECTED] wrote: No, because those are not linked together with the GPLed code, but are a mere aggregation of works inside the same media, i.e. the binary file. Those non-free firmware will never run inside the same memory space as the kernel, and are offloaded to a peripheral processor, and the communication media between the kernel and this peripheral processor running said firmware is clearly defined, there is no doubt that those non-free firmware do not break the kernel GPL. They are linked in, they have symbols, the code directly references their address. Can you name one tool that will easily remove such No. They are a char array, it's data copied where the hardware wants it. It's not code called by other functions. Yeah, exact, its mips or arm machine code, uploaded to the embedded core in the chip used for the peripheral in question. Often it isn't, unless you want to call the content of a configuration register bank code. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On Mon, Aug 07, 2006 at 06:24:12PM +0100, Thiemo Seufer wrote: Sven Luther wrote: On Mon, Aug 07, 2006 at 04:53:51PM +0200, Marco d'Itri wrote: On Aug 07, Goswin von Brederlow [EMAIL PROTECTED] wrote: No, because those are not linked together with the GPLed code, but are a mere aggregation of works inside the same media, i.e. the binary file. Those non-free firmware will never run inside the same memory space as the kernel, and are offloaded to a peripheral processor, and the communication media between the kernel and this peripheral processor running said firmware is clearly defined, there is no doubt that those non-free firmware do not break the kernel GPL. They are linked in, they have symbols, the code directly references their address. Can you name one tool that will easily remove such No. They are a char array, it's data copied where the hardware wants it. It's not code called by other functions. Yeah, exact, its mips or arm machine code, uploaded to the embedded core in the chip used for the peripheral in question. Often it isn't, unless you want to call the content of a configuration register bank code. Given that the specs of most of those chips are not available except under NDA, how would you make the difference ? And even then, once could consider that the definition of those registers are kind of part of the source to said code. But if you feel like it, go ahead, and provide us with the extensive list of all those cases, and provide evidence in how those firmware blobs are only register dumps, and then we can indeed let some of those in main. At least we would probably need the format of the register dump in question though. Also, this then has implications on the miboot boot sector, which is currently not even allowed in non-free, since there is no clear licencing about it, and apple doesn't care about decades old code. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
Sven Luther [EMAIL PROTECTED] writes: untruth in what i said above, or in the other mail ? Yes. There is the option of simply not supporting installation on the devices in question. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On Aug 08, Thomas Bushnell BSG [EMAIL PROTECTED] wrote: Yes. There is the option of simply not supporting installation on the devices in question. i.e. screwing our users. -- ciao, Marco signature.asc Description: Digital signature
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
[EMAIL PROTECTED] (Marco d'Itri) writes: On Aug 08, Thomas Bushnell BSG [EMAIL PROTECTED] wrote: Yes. There is the option of simply not supporting installation on the devices in question. i.e. screwing our users. We Do Not Distribute Non-Free Software No Matter How Much It Helps Our Users. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On Aug 08, Thomas Bushnell BSG [EMAIL PROTECTED] wrote: We Do Not Distribute Non-Free Software No Matter How Much It Helps Our Users. Now think about why we do not do it. -- ciao, Marco signature.asc Description: Digital signature
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
[EMAIL PROTECTED] (Marco d'Itri) writes: On Aug 08, Thomas Bushnell BSG [EMAIL PROTECTED] wrote: We Do Not Distribute Non-Free Software No Matter How Much It Helps Our Users. Now think about why we do not do it. It does not matter. Different members of Debian have different reasons. We have all agreed to work together on the basis of the Social Contract, which says that We Do Not Distribute Non-Free Software No Matter How Much It Helps Our Users. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On Aug 08, Thomas Bushnell BSG [EMAIL PROTECTED] wrote: Now think about why we do not do it. It does not matter. Different members of Debian have different reasons. We have all agreed to work together on the basis of the Social Contract, which says that We Do Not Distribute Non-Free Software No Matter How Much It Helps Our Users. I rest my case. -- ciao, Marco signature.asc Description: Digital signature
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
[EMAIL PROTECTED] (Marco d'Itri) writes: On Aug 08, Thomas Bushnell BSG [EMAIL PROTECTED] wrote: Now think about why we do not do it. It does not matter. Different members of Debian have different reasons. We have all agreed to work together on the basis of the Social Contract, which says that We Do Not Distribute Non-Free Software No Matter How Much It Helps Our Users. I rest my case. Your case that... what? That our users will be inconvenienced if we cannot support certain hardware in the installer? Yes, nobody has doubted this. But you have not given any argument for why this should in this one case override our principles, cause us to violate our own Social Contract, and otherwise simply abandon what Debian stands for. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On Mon, Aug 07, 2006 at 04:26:45PM -0700, Thomas Bushnell BSG wrote: Sven Luther [EMAIL PROTECTED] writes: untruth in what i said above, or in the other mail ? Yes. There is the option of simply not supporting installation on the devices in question. Yeah, well, sure there is, but given what those devices are, and the general outcry when we temporarily removed them in the past, i have some serious doubts about this really being a solution. But then, we where speaking about the 'inflamatory' part of those mails, not about the more technical part. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On Mon, Aug 07, 2006 at 04:46:09PM -0700, Thomas Bushnell BSG wrote: [EMAIL PROTECTED] (Marco d'Itri) writes: On Aug 08, Thomas Bushnell BSG [EMAIL PROTECTED] wrote: We Do Not Distribute Non-Free Software No Matter How Much It Helps Our Users. Now think about why we do not do it. It does not matter. Different members of Debian have different reasons. We have all agreed to work together on the basis of the Social Contract, which says that We Do Not Distribute Non-Free Software No Matter How Much It Helps Our Users. # Our priorities are our users and free software We will be guided by the needs of our users and the free software community. We will place their interests first in our priorities. We will support the needs of our users for operation in many different kinds of computing environments. We will not object to non-free works that are intended to be used on Debian systems, or attempt to charge a fee to people who create or use such works. We will allow others to create distributions containing both the Debian system and other works, without any fee from us. In furtherance of these goals, we will provide an integrated system of high-quality materials with no legal restrictions that would prevent such uses of the system. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On Tue, Aug 08, 2006 at 06:49:32AM +0200, Sven Luther [EMAIL PROTECTED] wrote: On Mon, Aug 07, 2006 at 04:46:09PM -0700, Thomas Bushnell BSG wrote: [EMAIL PROTECTED] (Marco d'Itri) writes: On Aug 08, Thomas Bushnell BSG [EMAIL PROTECTED] wrote: We Do Not Distribute Non-Free Software No Matter How Much It Helps Our Users. Now think about why we do not do it. It does not matter. Different members of Debian have different reasons. We have all agreed to work together on the basis of the Social Contract, which says that We Do Not Distribute Non-Free Software No Matter How Much It Helps Our Users. # Our priorities are our users and free software We will be guided by the needs of our users and the free software community. We will place their interests first in our priorities. We will support the needs of our users for operation in many different kinds of computing environments. We will not object to non-free works that are intended to be used on Debian systems, or attempt to charge a fee to people who create or use such works. We will allow others to create distributions containing both the Debian system and other works, without any fee from us. In furtherance of these goals, we will provide an integrated system of high-quality materials with no legal restrictions that would prevent such uses of the system. Where do you read we allow ourselves to distribute non-free software for user convenience ? Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
[EMAIL PROTECTED] (Marco d'Itri) writes: On Aug 04, Goswin von Brederlow [EMAIL PROTECTED] wrote: think not? Prove it by proposing a GR. More importantly, the release team I had such a plan, but no time to implement it currently. How do you handle the fact that it is a license violation making the thing illegal to distribute? I see that the lawyers of SuSE and Red Hat do not believe this to be true or at least do not consider it a problem, and this is enough for me to ignore the opinion of the debian-legal@ armchair lawyers. -- ciao, Marco I hope you do believe this to be true. Otherwise you would need to go back to NM and do the licensing section again. There can be no doubt that binaries without source or even a DO NOT DISTRIBUTE notice break the GPL. As to being a problem that depends if anyone ever sues, which is indeed unlikely. But Debian has also made a promise that main will be free. And the kernel breaks that. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On Saturday 05 August 2006 17:30, Marco d'Itri wrote:
In linux.debian.kernel Ron Johnson [EMAIL PROTECTED] wrote:
I see that the lawyers of SuSE and Red Hat do not believe this to be
true or at least do not consider it a problem, and this is enough for
me to ignore the opinion of the debian-legal@ armchair lawyers.
Could they have signed license agreements that we (not being
executives of RHAT and Novell) don't know about?
While it may be possible in theory, it's also very hard to believe.
If there are any signed license agreements, then they will probably drop some
notes in the {src}.rpm packages themselves they distribute to give their
users a clue, since these users are the most interested end to be aware of
that legal situation.
--
pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On Sun, Aug 06, 2006 at 01:21:32PM +0200, Goswin von Brederlow wrote: [EMAIL PROTECTED] (Marco d'Itri) writes: On Aug 04, Goswin von Brederlow [EMAIL PROTECTED] wrote: think not? Prove it by proposing a GR. More importantly, the release team I had such a plan, but no time to implement it currently. How do you handle the fact that it is a license violation making the thing illegal to distribute? I see that the lawyers of SuSE and Red Hat do not believe this to be true or at least do not consider it a problem, and this is enough for me to ignore the opinion of the debian-legal@ armchair lawyers. -- ciao, Marco I hope you do believe this to be true. Otherwise you would need to go back to NM and do the licensing section again. There can be no doubt that binaries without source or even a DO NOT DISTRIBUTE notice break the GPL. No, because those are not linked together with the GPLed code, but are a mere aggregation of works inside the same media, i.e. the binary file. Those non-free firmware will never run inside the same memory space as the kernel, and are offloaded to a peripheral processor, and the communication media between the kernel and this peripheral processor running said firmware is clearly defined, there is no doubt that those non-free firmware do not break the kernel GPL. There is a problem, as was the case for some of the firmware we where distributing, like the tg3 one, where there was no explicit licence for the firmware hexdump, and as thus, it was defacto placed under the GPL, and this means it is indeed undistributable. But this can easily be solvev by approaching those upstream guys and fixing the licencing issue with them, and before you all laugh about such an idea, this was done by Andres Salomon and me and a few others for such firmwares as the tg3 one from Broadcom, and they indeed did clear up the licencing. As to being a problem that depends if anyone ever sues, which is indeed unlikely. But Debian has also made a promise that main will be free. And the kernel breaks that. Indeed, and that is the problem here. We have two cases, first, there is the firmwares without source placed (by author's ignorance usually) under defacto GPL and undistributable, this we have to remove from both main or even non-free, and go the author contacting route (except in some cases, the copyright holder has been multiple-times bought up, and the new owner doesn't care, and everyone is screwed). The second case is easier, we have simply to remove the non-free firmware, and put it in non-free, and/or remove completely the non-free driver and put it in non-free. In the case of modules vital to boot the machine we are trully screwed here, and by some of ourselves even. The problem is that the installer people, who where told repeteadly by me and others about this issue since over 6 month, and should have worked on enabling the installer to load .udebs from multiple apt/anna sources and not just one, thus enabling to place those non-free .udebs into a separate non-free .udeb archive, and solve this problem neatly. But then, the d-i team, has prefered to ignore this issue, shot the messenger, and go into kicking out, witch hunts and diffamatory tactics in order to not face their own lack of vision and inadequateness, in the same way as their reaction to the kernel module .udeb proposal was over-agressive and now leaves us in mostly the same situation as we where at the sarge release time, with the d-i team incapacity to handle kernel abi bumps and security upgrades in a timely fashion. So, i don't believe there is much choice left to the kernel team in this issue but to ask for a waiver of the DFSG compliance for the kernel for etch, and hope the d-i folk take their responsabilities a bit more seriously for the etch+1 release. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
Marco d'Itri [EMAIL PROTECTED] writes: In linux.debian.kernel Sven Luther [EMAIL PROTECTED] wrote: The real issue here is one of freedom and DFSG and not one of legality anyway. Those firmware are not DFSG-free and have nothing to do in main, and this is the real problem. They were not a problem before the SC was clarified, so I do not expect that many people will suddenly care now. They have always been a problem and have always violated the license of the rest of the kernel. It is just that nobody noticed or cared before but now the cat is out of the sack and the issue is a release blocker. Sometimes ignorance is bliss. But now we have seen the (ugly) light. -- ciao, Marco MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
George Danchev wrote:
On Saturday 05 August 2006 17:30, Marco d'Itri wrote:
In linux.debian.kernel Ron Johnson [EMAIL PROTECTED] wrote:
I see that the lawyers of SuSE and Red Hat do not believe this to be
true or at least do not consider it a problem, and this is enough for
me to ignore the opinion of the debian-legal@ armchair lawyers.
Could they have signed license agreements that we (not being
executives of RHAT and Novell) don't know about?
While it may be possible in theory, it's also very hard to believe.
Because?
If there are any signed license agreements, then they will probably drop some
notes in the {src}.rpm packages themselves they distribute to give their
users a clue, since these users are the most interested end to be aware of
that legal situation.
Do any Debianites read SRC.RPM packages?
- --
Ron Johnson, Jr.
Jefferson LA USA
Is common sense really valid?
For example, it is common sense to white-power racists that
whites are superior to blacks, and that those with brown skins
are mud people.
However, that common sense is obviously wrong.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFE1mafS9HxQb37XmcRAhFkAJ46nS1OMTb8wfh8o8BhLJcFyBmacACguNyX
E3zH8yiy+axVb6EsSoCsfx8=
=mfDp
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
Sven Luther [EMAIL PROTECTED] writes: So, i don't believe there is much choice left to the kernel team in this issue but to ask for a waiver of the DFSG compliance for the kernel for etch, and hope the d-i folk take their responsabilities a bit more seriously for the etch+1 release. Or, the kernel team could actually comply with the DFSG for the first time ever. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On Sat, Aug 05, 2006 at 02:22:18AM +0200, Marco d'Itri wrote: On Aug 04, Goswin von Brederlow [EMAIL PROTECTED] wrote: think not? Prove it by proposing a GR. More importantly, the release team I had such a plan, but no time to implement it currently. How do you handle the fact that it is a license violation making the thing illegal to distribute? I see that the lawyers of SuSE and Red Hat do not believe this to be true or at least do not consider it a problem, and this is enough for me to ignore the opinion of the debian-legal@ armchair lawyers. This position was clear enough that broadcom and the other company holding the qlsomething firmware copyright, changed their licencing after sa lengthy lawyer consulting process. The real issue here is one of freedom and DFSG and not one of legality anyway. Those firmware are not DFSG-free and have nothing to do in main, and this is the real problem. We may (or not) distribute some of them in non-free, even though they are not clearly distributible, but that is the choice of the ftp-masters, and seeing how miboot was refused to go into non-free, because it holded a half-sector of m68k code without a clear licencing case (not withstanding that it is decades old, and every macos 10 had tools to create such floppies and distribute them), i doubt it would be consistent to keep it like that. As for non-distributability, it is moot, since those firmware don't need to be GPL compatibly, since they are just non-free stuff shipped inside the kernel media. But then there may be another license violation mentioned here. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
[EMAIL PROTECTED] (Marco d'Itri) writes: I see that the lawyers of SuSE and Red Hat do not believe this to be true or at least do not consider it a problem, and this is enough for me to ignore the opinion of the debian-legal@ armchair lawyers. We already know that the lawyers of SuSE and Red Hat often take a more lenient view than Debian (see the old KDE controversy for an example). I believe that this can be explained by the simple observation that they are content as long as they don't get sued, whereas we do our best to follow the licenses whether there is a likelihood of getting sued or not. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
Marco d'Itri [EMAIL PROTECTED] writes: I became a developer long before the NM process was created, and I agreed to follow the unclarified social contract. Are you unwilling to follow the current Social Contract? If so, you should resign, and yesterday. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
Marco d'Itri [EMAIL PROTECTED] writes: In linux.debian.kernel Nathanael Nerode [EMAIL PROTECTED] wrote: What can be done about this? Accept that most people do not consider this a problem? First of all, this is false. Most Debian developers agree with me. You This is unproven. It is also irelevant. The release team has made it a release blocker. Thez have decided this (following the SC discussions for sarge) for the project. You need to convence them or make a GR to change it. think not? Prove it by proposing a GR. More importantly, the release team I had such a plan, but no time to implement it currently. How do you handle the fact that it is a license violation making the thing illegal to distribute? agrees with me that this is a problem, and it is explicitly a release blocker. It's not like they had a choice. Exactly, neither do you. :) You probably agreed to uphold the Social Contract in your Debian work. (Or were you grandfathered in before NM?) I became a developer long before the NM process was created, and I agreed to follow the unclarified social contract. 'or any later version'? :) MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On Aug 04, Goswin von Brederlow [EMAIL PROTECTED] wrote: think not? Prove it by proposing a GR. More importantly, the release team I had such a plan, but no time to implement it currently. How do you handle the fact that it is a license violation making the thing illegal to distribute? I see that the lawyers of SuSE and Red Hat do not believe this to be true or at least do not consider it a problem, and this is enough for me to ignore the opinion of the debian-legal@ armchair lawyers. -- ciao, Marco signature.asc Description: Digital signature
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Marco d'Itri wrote: On Aug 04, Goswin von Brederlow [EMAIL PROTECTED] wrote: think not? Prove it by proposing a GR. More importantly, the release team I had such a plan, but no time to implement it currently. How do you handle the fact that it is a license violation making the thing illegal to distribute? I see that the lawyers of SuSE and Red Hat do not believe this to be true or at least do not consider it a problem, and this is enough for me to ignore the opinion of the debian-legal@ armchair lawyers. Could they have signed license agreements that we (not being executives of RHAT and Novell) don't know about? - -- Ron Johnson, Jr. Jefferson LA USA Is common sense really valid? For example, it is common sense to white-power racists that whites are superior to blacks, and that those with brown skins are mud people. However, that common sense is obviously wrong. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE1ANpS9HxQb37XmcRAmswAKDF5zCi6C4FIzDfGHvz2RPj2OgfaACbBwj8 A1nxGf1PgNvdXV1bwL090zM= =5gfY -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
In linux.debian.kernel Nathanael Nerode [EMAIL PROTECTED] wrote: What can be done about this? Accept that most people do not consider this a problem? First of all, this is false. Most Debian developers agree with me. You think not? Prove it by proposing a GR. More importantly, the release team agrees with me that this is a problem, and it is explicitly a release blocker. Further, majority opinion is irrelevant on issues of honesty. Debian is lying to its users. Debian needs to stop doing that. Frankly, I no longer care which way Debian becomes honest: (1) A GR amending the Social Contract to explicitly allow sourceless, non-free binary material in Debian (2) Removing the sourceless, non-free binary material from Debian main. Debian must do one of the two if it is to be honorable. I don't care which. You probably agreed to uphold the Social Contract in your Debian work. (Or were you grandfathered in before NM?) If so *you agreed* to remove this firmware. You have two honorable options: (1) Propose a GR amending the Social Contract to allow it. Please do so! (2) Remove it whenever it falls into your sphere of responsibility. You have historically chosen to take the dishonorable option, and I do not expect you to change, but I can hope. -- Nathanael Nerode [EMAIL PROTECTED] Read it and weep. http://rawstory.com/news/2005/Text_of_Gore_speech_0116.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
