[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 <sven.luther@wanadoo.fr> 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.


Sven Luther

Reply to: