[EMAIL PROTECTED] wrote:
>Uh, no. Whoever is creating an installer for main can just as easily
*WE* are creating an installer for main!
--
ciao,
Marco
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
On Sun, Jan 16, 2005 at 04:22:22PM +, Steve McIntyre wrote:
> Glenn Maynard wrote:
> >On Sun, Jan 16, 2005 at 02:01:22PM +, Matthew Garrett wrote:
> >> In many cases, the firmware may be provided by the hardware vendor in
> >> some form, so we can just use the existing media for install pur
Glenn Maynard wrote:
>On Sun, Jan 16, 2005 at 02:01:22PM +, Matthew Garrett wrote:
>> In many cases, the firmware may be provided by the hardware vendor in
>> some form, so we can just use the existing media for install purposes.
>> It's probably not reasonable to expect them to provide Debian
On Sun, Jan 16, 2005 at 02:01:22PM +, Matthew Garrett wrote:
> In many cases, the firmware may be provided by the hardware vendor in
> some form, so we can just use the existing media for install purposes.
> It's probably not reasonable to expect them to provide Debian installer
> modules as we
Sam Couter <[EMAIL PROTECTED]> wrote:
> Steve McIntyre <[EMAIL PROTECTED]> wrote:
>> Yes, quite a lot actually - we can then ask people to feed a floopy or
>> CD containing the vendor-supplied firmware. Do keep up...
>
> A floopy?
>
> Maybe I'm failing to keep up (I've obviously taken a long time
On Sat, Jan 15, 2005 at 09:30:48PM +1100, Sam Couter wrote:
> Steve McIntyre <[EMAIL PROTECTED]> wrote:
> > Yes, quite a lot actually - we can then ask people to feed a floopy or
> > CD containing the vendor-supplied firmware. Do keep up...
> A floopy?
> Maybe I'm failing to keep up (I've obvious
Steve McIntyre <[EMAIL PROTECTED]> wrote:
> Yes, quite a lot actually - we can then ask people to feed a floopy or
> CD containing the vendor-supplied firmware. Do keep up...
A floopy?
Maybe I'm failing to keep up (I've obviously taken a long time to get to
reading this message), but why can't th
On Wed, Jan 12, 2005 at 02:12:20PM -0800, Steve Langasek wrote:
> > That's the question that I see unanswered. Is the first motivation of
> > banning
> > non-free firmware from main to allow distribution consistent with DFSG
> > or is it because we want to promote free firmware (if realistic) ?
>
[EMAIL PROTECTED] wrote:
>> No, because in many situations the users would only need to copy the
>> firmware binary from media they already have, and installing a package
>> from a different archive (and even more a new udeb) requires more work
>> for them and for us.
>I imagine this firmware blob
On Wed, Jan 12, 2005 at 09:27:43PM +0100, Peter Vandenabeele wrote:
> On Wed, Jan 12, 2005 at 10:33:40AM +, Matthew Garrett wrote:
> > Manoj Srivastava <[EMAIL PROTECTED]> wrote:
> > > I must confess I do not see it that way. I think of Debian as
> > > distriuting softwware that runs
On Wed, Jan 12, 2005 at 10:33:40AM +, Matthew Garrett wrote:
> Manoj Srivastava <[EMAIL PROTECTED]> wrote:
>
> > I must confess I do not see it that way. I think of Debian as
> > distriuting softwware that runs on a platform, this platform consists
> > of hardware, and, perhaps, asso
> Once the hardware's out there, it's out there--I don't think the case of
> "all devices with firmware in flash have been tracked down and destroyed,
> so we have to move this driver back to contrib" is a serious worry.
I was thinking more of the cases, "skipping the firmware download used
to res
On Wed, Jan 12, 2005 at 12:17:05AM -0800, Michael K. Edwards wrote:
> Do you think it would be tolerable to exclude non-free firmware images
> from the kernel binary and modules themselves but to permit loading
> them from the initrd or the root filesystem? I. e., treat the
> firmware download fun
Manoj Srivastava <[EMAIL PROTECTED]> wrote:
> I must confess I do not see it that way. I think of Debian as
> distriuting softwware that runs on a platform, this platform consists
> of hardware, and, perhaps, associated software burned into
> ROM/flash. We do not distribute the hardware
On Wed, 12 Jan 2005 01:57:08 -0600, Manoj Srivastava
<[EMAIL PROTECTED]> wrote:
[snip]
> Software that resides on disk, however, lives on our side of
> the divide; the kernel, and the filesystem drivers are required to
> mediate delivery of this non-free payload to the system, and it can'
On Sun, 9 Jan 2005 14:00:51 +, Matthew Garrett <[EMAIL PROTECTED]> said:
> As you say, there's a couple of practical issues. There's also the
> fact that putting something in contrib is something of a judgement -
> we're saying that this driver needs non-free code to work, and as a
> result i
On Mon, Jan 10, 2005 at 07:37:22PM +0100, Marco d'Itri wrote:
> [EMAIL PROTECTED] wrote:
> >True enough. I have a harder time justifying to myself keeping such drivers
> >in main, but I also think that the infrastructure needed in order to support
> >grabbing firmware out of non-free (for things
On Sun, Jan 09, 2005 at 05:28:23PM +1100, Craig Sanders wrote:
> On Sun, Jan 09, 2005 at 02:36:03AM +, Matthew Garrett wrote:
> > In the firmware case, the choice is rather different. At present, the
> > choice is not between free firmware or non-free firmware. The choice is
> > between non-fre
On Mon, Jan 10, 2005 at 10:14:02AM -0800, Ben Pfaff wrote:
> I bet that, with some of these firmware blobs, we could
> reverse-engineer and "clean room" clone them in a country with
> permissive reverse engineering laws. At that point, we'd have
> something that was definitely free.
>
> Anyone in
[EMAIL PROTECTED] wrote:
>I bet that, with some of these firmware blobs, we could
>reverse-engineer and "clean room" clone them in a country with
>permissive reverse engineering laws. At that point, we'd have
>something that was definitely free.
I bet you could not, for interesting devices (DVB r
I bet that, with some of these firmware blobs, we could
reverse-engineer and "clean room" clone them in a country with
permissive reverse engineering laws. At that point, we'd have
something that was definitely free.
Anyone interested in trying?
--
"While the Melissa license is a bit unclear, Me
[EMAIL PROTECTED] wrote:
>True enough. I have a harder time justifying to myself keeping such drivers
>in main, but I also think that the infrastructure needed in order to support
>grabbing firmware out of non-free (for things like the installer) could
>easily work for the case of contrib driver
[EMAIL PROTECTED] wrote:
>Being in contrib doesn't mean that a work is evil, nor is contrib a
>second cousin to non-free.
It means that something is not part of debian and is not acceptable for
install media, which looks like a big enough problem to me.
It would be silly to be able to move a driv
[EMAIL PROTECTED] wrote:
>On Sun, Jan 09, 2005 at 03:22:45PM +0100, Martin Schulze wrote:
>> The larger problem is to identify non-free blobs in the main kernel,
>> extract them into non-free and modify the driver so that it is able
>> to load the blob from a user provided location; and include th
On Mon, Jan 10, 2005 at 05:35:59PM +, Steve McIntyre wrote:
> Andrew Suffield writes:
> >
> >On Sun, Jan 09, 2005 at 07:51:58PM +, Matthew Garrett wrote:
> >> > You also need to turn this question around and ask it the other way:
> >> > does having these drivers in contrib actually hurt any
Op ma, 10-01-2005 te 16:58 +, schreef Andrew Suffield:
> On Sun, Jan 09, 2005 at 07:51:58PM +, Matthew Garrett wrote:
> > > You also need to turn this question around and ask it the other way:
> > > does having these drivers in contrib actually hurt anything?
> >
> > Yes. It currently mean
Craig Sanders dijo [Sun, Jan 09, 2005 at 05:28:23PM +1100]:
> it's worse than just putting them in contrib. there's a whole bunch of
> drivers with firmware blobs that have just been deleted from the kernel
> sources. they're not in contrib, they're not in non-free, they're just gone.
>
> this a
Andrew Suffield writes:
>
>On Sun, Jan 09, 2005 at 07:51:58PM +, Matthew Garrett wrote:
>> > You also need to turn this question around and ask it the other way:
>> > does having these drivers in contrib actually hurt anything?
>>
>> Yes. It currently means that we can't ship an installer with
On Sun, Jan 09, 2005 at 07:51:58PM +, Matthew Garrett wrote:
> > You also need to turn this question around and ask it the other way:
> > does having these drivers in contrib actually hurt anything?
>
> Yes. It currently means that we can't ship an installer with support for
> this hardware, b
On Sun, Jan 09, 2005 at 03:21:40AM +, Matthew Garrett wrote:
> Steve Langasek <[EMAIL PROTECTED]> wrote:
> > I don't think I have a problem, conceptually, with a kernel package which
> > provides drivers for 10,000 different types of hardware, and needs to load
> > firmware from disk for 300 o
On Sun, 09 Jan 2005, Brian Nelson wrote:
> On Sun, Jan 09, 2005 at 02:53:52PM -0800, Don Armstrong wrote:
> > The whole purpose of contrib (at least in my mind) is to indicate
> > to users that they will need something extra from non-free or even
> > something we can't distribute to make useful use
On Sun, Jan 09, 2005 at 02:53:52PM -0800, Don Armstrong wrote:
> On Sun, 09 Jan 2005, Brian Nelson wrote:
> > On Sun, Jan 09, 2005 at 12:59:08PM -0500, Glenn Maynard wrote:
> > > No more nonsensical than the fact that code within a program that
> > > makes optional use of a non-free library can go
On Sun, 09 Jan 2005, Brian Nelson wrote:
> On Sun, Jan 09, 2005 at 12:59:08PM -0500, Glenn Maynard wrote:
> > No more nonsensical than the fact that code within a program that
> > makes optional use of a non-free library can go in main, while a
> > program consisting soley of that code must go in c
On Sun, Jan 09, 2005 at 03:28:43PM +0100, Martin Schulze wrote:
> Craig Sanders wrote:
> > this affects even DFSG-free drivers with DFSG-free patches. you often can't
> > apply the patches to the debianised kernel sources because the context that
> > the patch needs is missing.
> >
> > e.g. try d
On Sun, Jan 09, 2005 at 02:36:03AM +, Matthew Garrett wrote:
> It's becomingly increasingly common for hardware to require firmware to
> be loaded by the device driver on boot, rather than containing it in
> ROM. This is unfortunate, because in most cases the firmware is
> non-free. As a result
Andrew Suffield <[EMAIL PROTECTED]> wrote:
> On Sun, Jan 09, 2005 at 02:36:03AM +, Matthew Garrett wrote:
>> In the firmware case, the choice is rather different. At present, the
>> choice is not between free firmware or non-free firmware. The choice is
>> between non-free firmware on disk or n
On Sun, Jan 09, 2005 at 12:59:08PM -0500, Glenn Maynard wrote:
> On Sun, Jan 09, 2005 at 01:09:10AM -0800, Brian Nelson wrote:
> > It's also completely nonsensical that single drivers must go in contrib,
> > but a bundle of drivers may go in main as long as one of those drivers
> > does not use non
On Sun, Jan 09, 2005 at 02:36:03AM +, Matthew Garrett wrote:
> In the firmware case, the choice is rather different. At present, the
> choice is not between free firmware or non-free firmware. The choice is
> between non-free firmware on disk or non-free firmware in ROM. Putting
> drivers in co
On Sun, Jan 09, 2005 at 01:09:10AM -0800, Brian Nelson wrote:
> It's also completely nonsensical that single drivers must go in contrib,
> but a bundle of drivers may go in main as long as one of those drivers
> does not use non-free firmware.
No more nonsensical than the fact that code within a p
On Sun, Jan 09, 2005 at 03:21:40AM +, Matthew Garrett wrote:
> Steve Langasek <[EMAIL PROTECTED]> wrote:
>
> > I don't think I have a problem, conceptually, with a kernel package which
> > provides drivers for 10,000 different types of hardware, and needs to load
> > firmware from disk for 300
Glenn Maynard wrote:
> On Sun, Jan 09, 2005 at 03:22:45PM +0100, Martin Schulze wrote:
> > The larger problem is to identify non-free blobs in the main kernel,
> > extract them into non-free and modify the driver so that it is able
> > to load the blob from a user provided location; and include thi
Craig Sanders wrote:
> this affects even DFSG-free drivers with DFSG-free patches. you often can't
> apply the patches to the debianised kernel sources because the context that
> the patch needs is missing.
>
> e.g. try downloading the patch[1] for DVICO Fusion DVB-T card's DFSG-free
> driver and
On Sun, Jan 09, 2005 at 03:22:45PM +0100, Martin Schulze wrote:
> The larger problem is to identify non-free blobs in the main kernel,
> extract them into non-free and modify the driver so that it is able
> to load the blob from a user provided location; and include this in
> our installer.
Isn't
Matthew Garrett wrote:
> Steve Langasek <[EMAIL PROTECTED]> wrote:
>
> > I don't think I have a problem, conceptually, with a kernel package which
> > provides drivers for 10,000 different types of hardware, and needs to load
> > firmware from disk for 300 of them, being in main (without a
> > Dep
Joey Hess <[EMAIL PROTECTED]> wrote:
> Matthew Garrett wrote:
>> In the firmware case, the choice is rather different. At present, the
>> choice is not between free firmware or non-free firmware. The choice is
>> between non-free firmware on disk or non-free firmware in ROM. Putting
>> drivers in c
Matthew Garrett wrote:
> In the firmware case, the choice is rather different. At present, the
> choice is not between free firmware or non-free firmware. The choice is
> between non-free firmware on disk or non-free firmware in ROM. Putting
> drivers in contrib penalises the former, and as a resul
On Sun, Jan 09, 2005 at 02:36:03AM +, Matthew Garrett wrote:
> In the firmware case, the choice is rather different. At present, the
> choice is not between free firmware or non-free firmware. The choice is
> between non-free firmware on disk or non-free firmware in ROM. Putting
> drivers in co
Steve Langasek <[EMAIL PROTECTED]> wrote:
> I don't think I have a problem, conceptually, with a kernel package which
> provides drivers for 10,000 different types of hardware, and needs to load
> firmware from disk for 300 of them, being in main (without a
> Depends:/Recommends: relationship on t
On Sun, Jan 09, 2005 at 02:36:03AM +, Matthew Garrett wrote:
> An alternative would be to leave non-free firmware in non-free, but not
> to enforce the requirement that drivers depending on it end up in
> contrib. This is possibly the most straight forward, and by squinting
> funny we could po
It's becomingly increasingly common for hardware to require firmware to
be loaded by the device driver on boot, rather than containing it in
ROM. This is unfortunate, because in most cases the firmware is
non-free. As a result, a naive application of policy suggests that
drivers which require this
50 matches
Mail list logo
