Re: Re: linux-2.6: includes nondistributable and non-free binary firmware
No, what allowed sarge to go out the door with DFSG violations was an unambigous GR by a majority of the debian developers who decided to include those non-free firmware (and GFDL docs, and some random fonts, and ...), into sarge even though they didn't quite meet the DFSG. That vote is not valid for etch though, as we decided to waive that only for sarge, so only a new GR will allow debian to release the current kernel with non-free firmware as part of etch, independently of the migration scripts you are so worried about above. I disagree. If there's non-free material in main, that's a bug. Nothing in the Constitution or policy says that this class of bugs should be treated differently than all others, therefore the normal rule applies: for each unresolved bug, the release managers are ultimately in power to decide whether it's a release blocker or not. A General Resolution is only needed to _overrule_ the release managers' decision. The reason a GR was needed for Sarge was precisely that the then release manager, Anthony Towns, had stated that the non-free material in Sarge was a release blocker, so that had to be overruled. But if the current release team decides that Etch can be released, then it can be released. In fact, you'd need a GR to force them _not_ to release. Gerardo
gcj and etch freeze
Hi! Any chance gcj = 4.1.1-11j1 can make it into etch? Would be very nice to have gcjwebplugin-4.1. We'll have no browser java support otherwise. -- Robert Millan My spam trap is [EMAIL PROTECTED] Note: this address is only intended for spam harvesters. Writing to it will get you added to my black list. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gcj and etch freeze
On Fri, Aug 18, 2006 at 12:54:39PM +0200, Robert Millan wrote: Any chance gcj = 4.1.1-11j1 can make it into etch? gcj-4.1 hasn't been frozen yet, but whether this gets into etch depends on when it's uploaded. Would be very nice to have gcjwebplugin-4.1. We'll have no browser java support otherwise. Is gcjwebplugin in a presentable state yet? Last I knew, it still had serious security problems. (BTW, why does the plugin package need to have the upstream version number in its name?) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Request for binNMUs for the libxml++2.6 transition
On Tue, Aug 15, 2006 at 10:45:09AM +0200, Luk Claes wrote: Can someone please schedule binNMUs for: wormux_0.7.3-1, Rebuild against libxml++2.6-2, 1, alpha, amd64, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc gnomoradio_0.15.1-5, Rebuild against libxml++2.6-2, 2, alpha, amd64, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc synfigstudio_0.61.05-3, Rebuild against libxml++2.6-2, 1, alpha, amd64, hppa, i386, ia64, mips, mipsel, powerpc, s390, sparc bakery2.3_2.3.11-2, Rebuild against libxml++2.6-2, 1, alpha, amd64, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc buffy_0.11.2-1, Rebuild against libxml++2.6-2, 1, alpha, amd64, arm, hppa, i386, ia64, mips, mipsel, powerpc, s390, sparc gobby_0.3.1-2, Rebuild against libxml++2.6-2, 1, alpha, amd64, hppa, i386, ia64, mips, mipsel, powerpc, s390, sparc On Thu, Aug 17, 2006 at 01:05:09PM +0200, Loïc Minier wrote: libxml++2.6-1c2a was renamed to libxml++2.6-2, the following source packages would need a bin NMU: buffy wormux gobby synfigstudio bakery2.3 gnomoradio Concerning wormux, I'm not sure how it's control is updated from control.in, but the current debian/control seemed to permit bin NMUs. Done. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Please hint colo 1.22-1
On Wed, Aug 16, 2006 at 12:16:55PM +0200, Martin Michlmayr wrote: Can someone pleaes review and approve colo 1.22-1. It fixes a FTBFS bug. Hinted. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux-2.6: includes nondistributable and non-free binary firmware
Sven Luther wrote: On Thu, Aug 17, 2006 at 10:07:42AM -0700, [EMAIL PROTECTED] wrote: Maks - On Thu, Aug 17, 2006 at 06:05:30PM +0200, maximilian attems wrote: Something about [bug #242866] seems broken, however, because RC-buggy linux-2.6 packages keep making it into testing. Is it obvious how to keep this from happening, without starting a new bug attached to linux-2.6? if you feel like it reassign it, Bugs merged and assigned to linux-2.6. I think the kernel pseudo-package is mostly obsolete: it should be reserved for bugs affecting multiple kernels. This bug doesn't affect freebsd, hurd, etc. It does affect linux-2.4 and linux-2.2, but those are scheduled for removal before etch anyway. So actually, I'd like to suggest running through the bugs against 'kernel' and reassigning them to linux-2.6 or closing them as appropriate. Does that seem like a reasonable thing to do when I'm bored and not feeling up to programming, or would there be some complaint about it. snip anyway if you want to improve the legal situtation use: http://wiki.debian.org/KernelFirmwareLicensing dilinger succeeded in various firmware relicensing thanks to his quest to the vendors. feel free to pick up. Broadcom tg3 relicensing alone took over two years. This is a lovely thing to do, and I am *very very* impressed with dilinger's diligence and his success (I tried but failed to contact anyone at Broadcom). dgrs and qla2xxx are the only other drivers he had *any* success with, according to the wiki page. I am afraid we need a shorter-term solution. For each offending file, there are three possible solutions: 1. Get the author to release source code under a DFSG-free license 2. Move the firmware to non-free, patching the driver to use request_firmware() 3. Delete the driver and firmware entirely. 4. Move the whole friver to non-free, without major patching. 5. Reverse engineer the needed firmware, and create a trully free driver. AFAIK, the best outcome yet from the relicensing discussions on http://wiki.debian.org/KernelFirmwareLicensing is to properly permit the redistribution of the binary, without source code. Indeed, but even that was laughed at back then when we started at it, and you should have seen the reaction of LKML when i mentioned it there. Not to mention the reaction I originally got from the netdev maintainers, which was rather more hostile than being 'laughed at'. I think a lot of people genuinely believed that you could license an unsourced binary under the GPL I can't imagine *why* they believed that, though. snip That's fine for debian non-free, and a necessary step for making option (2) above work properly. Until and unless the entire Linux kernel is moved to non-free, such relicensing doesn't solve the fundamental bug. Indeed. I agree that option (3) is bad, but I still recommend it for the short term. It's the quickest path to a legal and For the short term, 4. is a better solution. Right. If a driver really can't build out-of-tree comfortably, (4) may not be feasible and (3) or (2) may be necessary, but let's cross that bridge if we come to it. What can I do to help with (4)? :-) SC-conforming Linux release, and it will bring people out of the closet to volunteer to work on (2). I think (2) is the actual goal, but maybe not one that can be finished before the proposed etch freeze -- especially since most of the blobs need to be relicensed before they can be made part of firmware-nonfree. Indeed, which is because we could also consider : 6. Pass another GR to allow debian/etch to release as is, provided we If the GR includes a commitment to include a statement regarding this violation of the SC in the *release notes*, then I would be satisfied with this from a freeness point of view: at least Debian would be advertising its failure to live up to the SC. If there is no such commitment, I would expect to see the same charade for etch+1. There's also a problem with Sven's analysis of option (6) relative to options (4) and (2). From a legal point of view, distributing the 'undistributable' (mislicensed) blobs in 'main' and distributing them in 'non-free' is equally bad. If it's OK to distribute them in the kernel package, it's OK to distribute them in 'firmware-nonfree'. It is up to the ftpmasters, the release team, and or the DPL to decide whether they are comfortable with it or not. If they are, then the blobs can be put in firmware-nonfree and (4) is perfectly straightforward. If they are not, then the blobs must be removed from the archive. (6) offers no advantage over (4) with regard to this. (This doesn't affect the non-free blobs which are properly licensed.) commit to a real effort to solve this for etch+1, or better yet, with some pro-active wording, which say we will make every effort to solve this issue, but don't provide timelines and schedules, as upstream will
