Re: kernel firmwares: GR proposal
Sven Luther wrote:
> On Wed, Aug 30, 2006 at 08:47:08PM -0400, Nathanael Nerode wrote:
<snip>
> http://www.debian.org/devel/debian-installer will give you all the links
> you want, but for the lazy :
> svn://svn.debian.org/svn/d-i/trunk/packages/anna
Thank you very much.
Oddly, finding the d-i repo was impossible for me until you provided this
link. It's not linked from the above page (it is linked from the Wiki page
linked from the above page, but I hadn't wandered that particular path) and
I didn't guess its name, so I couldn't find it at http://svn.debian.org/ .
> Also, it is in the main/debian-installer section of the debian archive,
> even with source and all.
I found it shortly after posting this. ::embarassed::
I had done dozens of searches, but I didn't think to look for a package
which existed only in the debian-installer section of the archive.
Ended up finding it via google; I managed to put in just the right search
terms finally.
'Course, it looks like 'anna' doesn't need any changes.... :-/
>> > and we do not
>> > want to depend on that (and even then, we still would have non-free
>> > firmware, see above). But since there is lots of hardware which needs
>> > firmware for correct operation, the installer would not work for
>> > mainstream hardware otherwise.
>> >
>> > There are two ways how to deal with it:
>> > 1. Accept these issues as transitional issues for now; or
>> > 2. Delay etch for some serious time.
>>
>> Like a month or two, maybe. If people actually bother to work on it, or
>> to accept other people's work on it.
>
> Current estimates place this between 6 month and a year. The fact is the
> d-i team need at least a month or two of testing for this,
Yeah, testing is an issue.
On the other hand, releasing a fully free etch by simply removing hardware
support would be fast and trivial, and etch wouldn't be delayed *at all*.
(Obviously the priorities of 'our users' and 'free software' come into
conflict there.)
If etch will be released in a hurry ("Debian releases before it is
ready"), I'd rather see an etch weak on hardware support and strong on
freedom; I guess others would prefer the other way around.
Actually, this is what is wrong with the polls at the debian user forums
which AJ pointed people to. Etch can release on time either free (with
less hardware support) or non-free (with more hardware support).
Making "Release etch on time" top priority doesn't really answer the
question of what to do.
> even if the
> change was instantaneous, there are loads of packages which will trigger
> NEW, and so on.
Yeah, that could slow things down.
> Also, finding, approaching and convincing people to clarify the licence of
> the problematic ones, is something which will take some serious time.
Years. Decades. Centuries. OK, I'm a bit pessimistic on this.
<snip lots of stuff where I basically agree with Sven>
>> > In our social contract, we promised that the users and the free
>> > software community are our priorities. We firmly believe that our users
>> > profit very much from releasing etch in time, and that this is
>> > important enough that we can accept the transitional status with having
>> > a few firmware
>> > images left in main that should belong somewhere else. Of course,
>> > everyone who wants to make the number of such firmware images as small
>> > as possible is welcome to help converting old firmware loaders to the
>> > new standard, and working on the Debian installer. We are happy if this
>> > issues become smaller or even vanishes, but we do not want this to be a
>> > release blocker.
>>
>> OK, this is good. :-) Does this mean that the patches converting the
>> tg3 driver to use firmware loading will be reaccepted?
>
> What is the position of the upstream author of the tg3 driver about this,
I recall little but emotional hostility, but I haven't asked in a while.
Maybe I'll try again when the patch is ready against the latest upstream.
> and even if he is still (i think it was him) strongly opposed, is your
> patch upstream-quality ?
It was used for months without complaints by many people; it's minimally
invasive; the one identified bug was fixed by Herbert Xu, although I
currently don't have a copy of his bugfix.
Currently other people are working on updating it to the current kernel,
which suits me fine. :-)
<snip lots of stuff where I basically agree with Sven>
>> Note that I am not comfortable personally working on the drivers
>> containing improperly licensed firmware. (Except for working on getting
>> a
>> proper license, that is.) You may well find that the other volunteers
>> for
>
> Yeah, that is something which is needed. We need someone to go over
> larry's list, which i have copiedto the debian wiki, and find out who the
> copyright holder of those problematic firmwares are, and then we can
> contact them, taking the broadcom original letter i wrote as a sample.
How optimistic you are. :-) After four or five attempts to find a contact
address at Broadcom which would reply, I gave up; I'm glad someone else
found one eventually.
I think that throwing Debian's name around with 'offical' status may
be helpful to get responses from some of these companies; I didn't do that,
since I couldn't!
>> converting drivers to firmware loading are not comfortable working on
>> them
>> either. This is bound to be a problem, given that the number of BLOBs
>> with good, clear licenses is quite small.
>
> Bah.
--
Nathanael Nerode <neroden@fastmail.fm>
Bush admitted to violating FISA and said he was proud of it.
So why isn't he in prison yet?...
Reply to: