On Wed, Jan 11, 2006 at 08:49:33AM +0100, Sven Luther wrote:
CCing the release team, since this has impact on the releasability of etch.
Oops, forgot to add the CC, ...
On Tue, Jan 10, 2006 at 09:00:57PM -0600, Manoj Srivastava wrote:
On Tue, 10 Jan 2006 23:53:03 +0100, Sven Luther [EMAIL
* Sven Luther ([EMAIL PROTECTED]) [060110 21:16]:
On Tue, Jan 10, 2006 at 05:19:47PM +0100, Andreas Barth wrote:
difference to this. It might however make an difference to
GPL-compatibility, unless the license is GPL-compatible anyways.
Nope, please read my posts on debian-legal about this
On Tue, Jan 10, 2006 at 09:13:27PM +0100, Sven Luther wrote:
how can you consider it as non-program. It is indeed composed of machine code
destined to run on the controller of the device the driver is written for.
This is incorrect. I know firmware[tm] blobs which only includes data.
You can't
On Wed, Jan 11, 2006 at 12:56:44PM +0100, Bastian Blank wrote:
On Tue, Jan 10, 2006 at 09:13:27PM +0100, Sven Luther wrote:
how can you consider it as non-program. It is indeed composed of machine
code
destined to run on the controller of the device the driver is written for.
This is
* Bastian Blank ([EMAIL PROTECTED]) [060111 12:57]:
On Tue, Jan 10, 2006 at 09:13:27PM +0100, Sven Luther wrote:
how can you consider it as non-program. It is indeed composed of machine
code
destined to run on the controller of the device the driver is written for.
This is incorrect. I
Bastian Blank wrote:
On Tue, Jan 10, 2006 at 09:13:27PM +0100, Sven Luther wrote:
how can you consider it as non-program. It is indeed composed of machine
code destined to run on the controller of the device the driver is
written for.
This is incorrect. I know firmware[tm] blobs which only
Andreas Barth wrote:
* Bastian Blank ([EMAIL PROTECTED]) [060111 12:57]:
On Tue, Jan 10, 2006 at 09:13:27PM +0100, Sven Luther wrote:
how can you consider it as non-program. It is indeed composed of
machine code destined to run on the controller of the device the driver
is written for.
On Wed, Jan 11, 2006 at 12:14:10PM -0500, Nathanael Nerode wrote:
Sven Luther wrote:
2) there are now drivers which contains non-free firmware blobs, with
explicit licence, and these are thus distributable. A quick search for
fw_ revealed 159 such files in 2.6.15.
I would like to
Kyle McMartin wrote:
The question is: when you remove the firmware from the driver, and all
it is, is a file sitting in /lib/firmware/; and it's contents are just
non-executable hex,
Sorry, it is executable. For instance, the tg3 code is simply MIPS binary
which can be disassembled with
[EMAIL PROTECTED] wrote:
licenced modules. If we don't want to do that, the most honest way to
handle it is to get another GR out the door,explaining that this is not
easily possible or convenient at this time, and asking for an explicit
exception for kernel firmware. I would second such a GR.
I
Nathanael Nerode wrote:
Second, the issues with the installer
--
Your analysis of the modules that would be needed by the installer does
not take all possible installation methods and hardware combinations
into account, notably missing a) network cards b)
Steve Langasek wrote:
the fact that the mips/mipsel guys do their own thing in their own way is i
believe etch-RC though, and need to be solved in the next 6 month.
That's a decision that needs to be made together with the people who will be
doing security support for the kernel in etch.
On Wed, Jan 11, 2006 at 10:16:59PM +0100, Moritz Muehlenhoff wrote:
Steve Langasek wrote:
the fact that the mips/mipsel guys do their own thing in their own way is i
believe etch-RC though, and need to be solved in the next 6 month.
That's a decision that needs to be made together with
Steve Langasek [EMAIL PROTECTED] wrote:
while this *particular* spurious dependency will go away with a
simple rebuild of the application (already queued on the
autobuilders for each of these packages BTW), the underlying problem
is that these packages don't have very good library handling .
On Wed, Jan 11, 2006 at 07:08:14PM -0500, Jay Berkenbilt wrote:
Steve Langasek [EMAIL PROTECTED] wrote:
while this *particular* spurious dependency will go away with a
simple rebuild of the application (already queued on the
autobuilders for each of these packages BTW), the underlying
On Wed, Jan 11, 2006 at 10:16:59PM +0100, Moritz Muehlenhoff wrote:
Steve Langasek wrote:
the fact that the mips/mipsel guys do their own thing in their own way is i
believe etch-RC though, and need to be solved in the next 6 month.
That's a decision that needs to be made together with the
* Steve Langasek [EMAIL PROTECTED] [2006-01-11 17:31]:
The mips kernels, though built from a separate source package, use
the sources from the common kernel source package via a
build-dependency.
This discussion is a waste of time anyway. There's no religious
reason why the mips kernel is not
Hi there!
Due to the xlibs-dev transition, I intend to NMU the following packages:
===
| Intend to NMU |
===
| 346347
18 matches
Mail list logo
