Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Nathanael Nerode]

The kernel freeze must be delayed quite significantly for a fairly obvious 
reason: the Debian kernel *still* has a lot of non-free and sourceless firmware 
in 
it.  Unfortunately, little to no progress has been made on this.

I'm sorry to be the bearer of bad news, but this is pretty obvious from looking 
at the
linux-source-2.6.17 package: they're not trying very hard.

Start with drivers/char/drm/mga_ucode.h.  This is distributable, because it's 
under
a BSD license, but it's not free software, because there's no source code.
Continue with drivers/chare/drm/radeon_cp.h.  This is "from ATI" and has no
copyright notices from ATI or license from ATI, so it's likely undistributable.

And those are two of the more prominent ones.  I could list dozens.

If people will not take the firmware issue seriously, either etch will not 
release
on time, or etch will be *yet another* release where Debian *breaks* its Social 
Contract.

My patches for firmware loading for tg3 have been *removed* from the Debian 
kernel.
drivers/net/tg3.c *again* contains the proprietary firmware, compiled into the 
kernel.
At least it has proper copyright and license notices, so it's distributable, but
it's *still non-free*.  This is a positive disincentive to work on fixing these 
issues:
my fully functional work was simply rejected in favor of breaking the Social
Contract.

What can be done about this?  If there is no plan for progress, I intend to file
'serious' bugs against each kernel package for each piece of firmware, which 
might
at least make *someone* pay *some* attention.

-- 
Nathanael Nerode 
<[EMAIL PROTECTED]>

This space intentionally left blank.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Nathanael Nerode]

>In linux.debian.kernel Nathanael Nerode <[EMAIL PROTECTED]> wrote:
>
>>What can be done about this?
>Accept that most people do not consider this a problem?

First of all, this is false.  Most Debian developers agree with me.  You
think not?  Prove it by proposing a GR.  More importantly, the release team
agrees with me that this is a problem, and it is explicitly a release blocker.

Further, majority opinion is irrelevant on issues of honesty.  Debian is 
lying to its users.  Debian needs to stop doing that.

Frankly, I no longer care which way Debian becomes honest:
(1) A GR amending the Social Contract to explicitly allow sourceless, non-free
binary material in Debian
(2) Removing the sourceless, non-free binary material from Debian main.

Debian must do one of the two if it is to be honorable.  I don't care which.

You probably agreed to uphold the Social Contract in your Debian work.
(Or were you "grandfathered in" before NM?)
If so *you agreed* to remove this firmware.  You have two honorable
options:

(1) Propose a GR amending the Social Contract to allow it.  Please do so!
(2) Remove it whenever it falls into your sphere of responsibility.

You have historically chosen to take the dishonorable option, and I do
not expect you to change, but I can hope.

-- 
Nathanael Nerode 
<[EMAIL PROTECTED]>

Read it and weep.
http://rawstory.com/news/2005/Text_of_Gore_speech_0116.html


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Goswin von Brederlow]

Marco d'Itri <[EMAIL PROTECTED]> writes:

> In linux.debian.kernel Nathanael Nerode <[EMAIL PROTECTED]> wrote:
>
What can be done about this?
>>>Accept that most people do not consider this a problem?
>>First of all, this is false.  Most Debian developers agree with me.  You
> This is unproven.

It is also irelevant.

The release team has made it a release blocker. Thez have decided this
(following the SC discussions for sarge) for the project. You need to
convence them or make a GR to change it.

>>think not?  Prove it by proposing a GR.  More importantly, the release team
> I had such a plan, but no time to implement it currently.

How do you handle the fact that it is a license violation making the
thing illegal to distribute?

>>agrees with me that this is a problem, and it is explicitly a release blocker.
> It's not like they had a choice.

Exactly, neither do you. :)

>>You probably agreed to uphold the Social Contract in your Debian work.
>>(Or were you "grandfathered in" before NM?)
> I became a developer long before the NM process was created, and I
> agreed to follow the "unclarified" social contract.

'or any later version'? :)

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Marco d'Itri]

On Aug 04, Goswin von Brederlow <[EMAIL PROTECTED]> wrote:

> >>think not?  Prove it by proposing a GR.  More importantly, the release team
> > I had such a plan, but no time to implement it currently.
> How do you handle the fact that it is a license violation making the
> thing illegal to distribute?
I see that the lawyers of SuSE and Red Hat do not believe this to be
true or at least do not consider it a problem, and this is enough for
me to ignore the opinion of the debian-legal@ armchair lawyers.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Ron Johnson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Marco d'Itri wrote:
> On Aug 04, Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
> 
 think not?  Prove it by proposing a GR.  More importantly, the release team
>>> I had such a plan, but no time to implement it currently.
>> How do you handle the fact that it is a license violation making the
>> thing illegal to distribute?
> I see that the lawyers of SuSE and Red Hat do not believe this to be
> true or at least do not consider it a problem, and this is enough for
> me to ignore the opinion of the debian-legal@ armchair lawyers.

Could they have signed license agreements that we (not being
executives of RHAT and Novell) don't know about?

- --
Ron Johnson, Jr.
Jefferson LA  USA

Is "common sense" really valid?
For example, it is "common sense" to white-power racists that
whites are superior to blacks, and that those with brown skins
are mud people.
However, that "common sense" is obviously wrong.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFE1ANpS9HxQb37XmcRAmswAKDF5zCi6C4FIzDfGHvz2RPj2OgfaACbBwj8
A1nxGf1PgNvdXV1bwL090zM=
=5gfY
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Sven Luther]

On Sat, Aug 05, 2006 at 02:22:18AM +0200, Marco d'Itri wrote:
> On Aug 04, Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
> 
> > >>think not?  Prove it by proposing a GR.  More importantly, the release 
> > >>team
> > > I had such a plan, but no time to implement it currently.
> > How do you handle the fact that it is a license violation making the
> > thing illegal to distribute?
> I see that the lawyers of SuSE and Red Hat do not believe this to be
> true or at least do not consider it a problem, and this is enough for
> me to ignore the opinion of the debian-legal@ armchair lawyers.

This position was clear enough that broadcom and the other company holding the
qlsomething firmware copyright, changed their licencing after sa lengthy
lawyer consulting process. 

The real issue here is one of freedom and DFSG and not one of legality anyway.
Those firmware are not DFSG-free and have nothing to do in main, and this is
the real problem. We may (or not) distribute some of them in non-free, even
though they are not clearly distributible, but that is the choice of the
ftp-masters, and seeing how miboot was refused to go into non-free, because it
holded a half-sector of m68k code without a clear licencing case (not
withstanding that it is decades old, and every macos <10 had tools to create
such floppies and distribute them), i doubt it would be consistent to keep it
like that.

As for non-distributability, it is moot, since those firmware don't need to be
GPL compatibly, since they are just non-free stuff shipped inside the kernel
media. But then there may be another license violation mentioned here.

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Thomas Bushnell BSG]

[EMAIL PROTECTED] (Marco d'Itri) writes:

> I see that the lawyers of SuSE and Red Hat do not believe this to be
> true or at least do not consider it a problem, and this is enough for
> me to ignore the opinion of the debian-legal@ armchair lawyers.

We already know that the lawyers of SuSE and Red Hat often take a more
lenient view than Debian (see the old KDE controversy for an
example).  I believe that this can be explained by the simple
observation that they are content as long as they don't get sued,
whereas we do our best to follow the licenses whether there is a
likelihood of getting sued or not.

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Thomas Bushnell BSG]

Marco d'Itri <[EMAIL PROTECTED]> writes:

> I became a developer long before the NM process was created, and I
> agreed to follow the "unclarified" social contract.

Are you unwilling to follow the current Social Contract?  If so, you
should resign, and yesterday.

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Goswin von Brederlow]

[EMAIL PROTECTED] (Marco d'Itri) writes:

> On Aug 04, Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
>
>> >>think not?  Prove it by proposing a GR.  More importantly, the release team
>> > I had such a plan, but no time to implement it currently.
>> How do you handle the fact that it is a license violation making the
>> thing illegal to distribute?
> I see that the lawyers of SuSE and Red Hat do not believe this to be
> true or at least do not consider it a problem, and this is enough for
> me to ignore the opinion of the debian-legal@ armchair lawyers.
>
> -- 
> ciao,
> Marco

I hope you do believe this to be true. Otherwise you would need to go
back to NM and do the licensing section again. There can be no doubt
that binaries without source or even a "DO NOT DISTRIBUTE" notice
break the GPL.

As to being a problem that depends if anyone ever sues, which is
indeed unlikely.

But Debian has also made a promise that main will be free. And the
kernel breaks that.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[George Danchev]

On Saturday 05 August 2006 17:30, Marco d'Itri wrote:
> In linux.debian.kernel Ron Johnson <[EMAIL PROTECTED]> wrote:
> >> I see that the lawyers of SuSE and Red Hat do not believe this to be
> >> true or at least do not consider it a problem, and this is enough for
> >> me to ignore the opinion of the debian-legal@ armchair lawyers.
> >
> >Could they have signed license agreements that we (not being
> >executives of RHAT and Novell) don't know about?
>
> While it may be possible in theory, it's also very hard to believe.

If there are any signed license agreements, then they will probably drop some 
notes in the {src}.rpm packages themselves they distribute to give their 
users a clue, since these users are the most interested end to be aware of 
that legal situation.

-- 
pub 4096R/0E4BD0AB 2003-03-18 
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Sven Luther]

On Sun, Aug 06, 2006 at 01:21:32PM +0200, Goswin von Brederlow wrote:
> [EMAIL PROTECTED] (Marco d'Itri) writes:
> 
> > On Aug 04, Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
> >
> >> >>think not?  Prove it by proposing a GR.  More importantly, the release 
> >> >>team
> >> > I had such a plan, but no time to implement it currently.
> >> How do you handle the fact that it is a license violation making the
> >> thing illegal to distribute?
> > I see that the lawyers of SuSE and Red Hat do not believe this to be
> > true or at least do not consider it a problem, and this is enough for
> > me to ignore the opinion of the debian-legal@ armchair lawyers.
> >
> > -- 
> > ciao,
> > Marco
> 
> I hope you do believe this to be true. Otherwise you would need to go
> back to NM and do the licensing section again. There can be no doubt
> that binaries without source or even a "DO NOT DISTRIBUTE" notice
> break the GPL.

No, because those are not linked together with the GPLed code, but are a mere
aggregation of works inside the same media, i.e. the binary file. Those
non-free firmware will never run inside the same memory space as the kernel,
and are offloaded to a peripheral processor, and the communication media
between the kernel and this peripheral processor running said firmware is
clearly defined, there is no doubt that those non-free firmware do not break
the kernel GPL.

There is a problem, as was the case for some of the firmware we where
distributing, like the tg3 one, where there was no explicit licence for the
firmware hexdump, and as thus, it was defacto placed under the GPL, and this
means it is indeed undistributable.

But this can easily be solvev by approaching those upstream guys and fixing
the licencing issue with them, and before you all laugh about such an idea,
this was done by Andres Salomon and me and a few others for such firmwares as
the tg3 one from Broadcom, and they indeed did clear up the licencing.

> As to being a problem that depends if anyone ever sues, which is
> indeed unlikely.
> 
> But Debian has also made a promise that main will be free. And the
> kernel breaks that.

Indeed, and that is the problem here. We have two cases, first, there is the
firmwares without source placed (by author's ignorance usually) under defacto
GPL and undistributable, this we have to remove from both main or even
non-free, and go the author contacting route (except in some cases, the
copyright holder has been multiple-times bought up, and the new owner doesn't
care, and everyone is screwed).

The second case is easier, we have simply to remove the non-free firmware, and
put it in non-free, and/or remove completely the non-free driver and put it in
non-free. In the case of modules vital to boot the machine we are trully
screwed here, and by some of ourselves even.

The problem is that the installer people, who where told repeteadly by me and
others about this issue since over 6 month, and should have worked on enabling
the installer to load .udebs from multiple apt/anna sources and not just one,
thus enabling to place those non-free .udebs into a separate non-free .udeb
archive, and solve this problem neatly.

But then, the d-i team, has prefered to ignore this issue, shot the messenger,
and go into kicking out, witch hunts and diffamatory tactics in order to not
face their own lack of vision and inadequateness, in the same way as their
reaction to the kernel module .udeb proposal was over-agressive and now leaves
us in mostly the same situation as we where at the sarge release time, with
the d-i team incapacity to handle kernel abi bumps and security upgrades in a
timely fashion.

So, i don't believe there is much choice left to the kernel team in this issue
but to ask for a waiver of the DFSG compliance for the kernel for etch, and
hope the d-i folk take their responsabilities a bit more seriously for the
etch+1 release.

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Goswin von Brederlow]

Marco d'Itri <[EMAIL PROTECTED]> writes:

> In linux.debian.kernel Sven Luther <[EMAIL PROTECTED]> wrote:
>>The real issue here is one of freedom and DFSG and not one of legality anyway.
>>Those firmware are not DFSG-free and have nothing to do in main, and this is
>>the real problem.
> They were not a problem before the SC was "clarified", so I do not
> expect that many people will suddenly care now.

They have always been a problem and have always violated the license
of the rest of the kernel. It is just that nobody noticed or cared
before but now the cat is out of the sack and the issue is a release
blocker.

Sometimes ignorance is bliss. But now we have seen the (ugly) light.

> -- 
> ciao,
> Marco

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Ron Johnson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

George Danchev wrote:
> On Saturday 05 August 2006 17:30, Marco d'Itri wrote:
>> In linux.debian.kernel Ron Johnson <[EMAIL PROTECTED]> wrote:
 I see that the lawyers of SuSE and Red Hat do not believe this to be
 true or at least do not consider it a problem, and this is enough for
 me to ignore the opinion of the debian-legal@ armchair lawyers.
>>> Could they have signed license agreements that we (not being
>>> executives of RHAT and Novell) don't know about?
>> While it may be possible in theory, it's also very hard to believe.

Because?

> If there are any signed license agreements, then they will probably drop some 
> notes in the {src}.rpm packages themselves they distribute to give their 
> users a clue, since these users are the most interested end to be aware of 
> that legal situation.

Do any Debianites read SRC.RPM packages?

- --
Ron Johnson, Jr.
Jefferson LA  USA

Is "common sense" really valid?
For example, it is "common sense" to white-power racists that
whites are superior to blacks, and that those with brown skins
are mud people.
However, that "common sense" is obviously wrong.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFE1mafS9HxQb37XmcRAhFkAJ46nS1OMTb8wfh8o8BhLJcFyBmacACguNyX
E3zH8yiy+axVb6EsSoCsfx8=
=mfDp
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Thomas Bushnell BSG]

Sven Luther <[EMAIL PROTECTED]> writes:

> So, i don't believe there is much choice left to the kernel team in
> this issue but to ask for a waiver of the DFSG compliance for the
> kernel for etch, and hope the d-i folk take their responsabilities a
> bit more seriously for the etch+1 release.

Or, the kernel team could actually comply with the DFSG for the first
time ever.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Sven Luther]

On Sun, Aug 06, 2006 at 04:50:54PM -0700, Thomas Bushnell BSG wrote:
> Sven Luther <[EMAIL PROTECTED]> writes:
> 
> > So, i don't believe there is much choice left to the kernel team in
> > this issue but to ask for a waiver of the DFSG compliance for the
> > kernel for etch, and hope the d-i folk take their responsabilities a
> > bit more seriously for the etch+1 release.
> 
> Or, the kernel team could actually comply with the DFSG for the first
> time ever.

These are fine words, but how do you think they can translate into reality ?
We don't currently have the ressources to do it the way it should be done, and
evne if we did, the deficiencies of d-i will make the work we do useless.

But then, you could help, and put your actions where your mouth is, by
helping in the elaboration of an exhaustive list of such problematic firmware
hexdumps, together with their licencing conditions, their copyright holder,
and a summary of what the module is good for.

This stands for anyone having a similar discourse to yours too :)

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Frederik Schueler]

Hello,

On Mon, Aug 07, 2006 at 09:32:11AM +0200, Sven Luther wrote:
> These are fine words, but how do you think they can translate into reality ?
> We don't currently have the ressources to do it the way it should be done, and
> evne if we did, the deficiencies of d-i will make the work we do useless.
 
Sven, can you please finally STOP flaming against the debian-installer team,
thank you.


> But then, you could help, and put your actions where your mouth is, by
> helping in the elaboration of an exhaustive list of such problematic firmware
> hexdumps, together with their licencing conditions, their copyright holder,
> and a summary of what the module is good for.

I agree, everyone who wants to see the firmware issue solved should
either start doing something about it or be silent.

here is an outdated wiki document, where to start with:

http://wiki.debian.org/KernelFirmwareLicensing


Best regards
Frederik Schueler

-- 
ENOSIG


signature.asc
Description: Digital signature

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Sven Luther]

On Mon, Aug 07, 2006 at 10:23:31AM +0200, Frederik Schueler wrote:
> Hello,
> 
> On Mon, Aug 07, 2006 at 09:32:11AM +0200, Sven Luther wrote:
> > These are fine words, but how do you think they can translate into reality ?
> > We don't currently have the ressources to do it the way it should be done, 
> > and
> > evne if we did, the deficiencies of d-i will make the work we do useless.
>  
> Sven, can you please finally STOP flaming against the debian-installer team,
> thank you.

Well, its a simple statement of facts, is it not ? I mean, did you find any
untruth in what i said above, or in the other mail ? It has a direct bearing
over the problem at hand, and a certain subset of the d-i folk exhibited
inacceptable behaviour against me over it, so it is only just that their
errors and inadequacies are remembered when we speak about these topics, since
it was me trying to speak about those topics wich pushed them in the first
place to start the witch hunt against me, and nothing i can do can in any way
change the current mess, even the DPL in his attempted second mediation came
to the conclusion that i should just fork d-i or something.

So, no, i will not stop this, and i will never forget what they did to me, nor
the circunstances in which they did it, i tried mutliple times, but it was
rejected out of hand, so ...

> > But then, you could help, and put your actions where your mouth is, by
> > helping in the elaboration of an exhaustive list of such problematic 
> > firmware
> > hexdumps, together with their licencing conditions, their copyright holder,
> > and a summary of what the module is good for.
> 
> I agree, everyone who wants to see the firmware issue solved should
> either start doing something about it or be silent.
> 
> here is an outdated wiki document, where to start with:
> 
> http://wiki.debian.org/KernelFirmwareLicensing

Thanks for the hint.

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Goswin von Brederlow]

Sven Luther <[EMAIL PROTECTED]> writes:

> On Sun, Aug 06, 2006 at 01:21:32PM +0200, Goswin von Brederlow wrote:
>> [EMAIL PROTECTED] (Marco d'Itri) writes:
>> 
>> > On Aug 04, Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
>> >
>> >> >>think not?  Prove it by proposing a GR.  More importantly, the release 
>> >> >>team
>> >> > I had such a plan, but no time to implement it currently.
>> >> How do you handle the fact that it is a license violation making the
>> >> thing illegal to distribute?
>> > I see that the lawyers of SuSE and Red Hat do not believe this to be
>> > true or at least do not consider it a problem, and this is enough for
>> > me to ignore the opinion of the debian-legal@ armchair lawyers.
>> >
>> > -- 
>> > ciao,
>> > Marco
>> 
>> I hope you do believe this to be true. Otherwise you would need to go
>> back to NM and do the licensing section again. There can be no doubt
>> that binaries without source or even a "DO NOT DISTRIBUTE" notice
>> break the GPL.
>
> No, because those are not linked together with the GPLed code, but are a mere
> aggregation of works inside the same media, i.e. the binary file. Those
> non-free firmware will never run inside the same memory space as the kernel,
> and are offloaded to a peripheral processor, and the communication media
> between the kernel and this peripheral processor running said firmware is
> clearly defined, there is no doubt that those non-free firmware do not break
> the kernel GPL.

They are linked in, they have symbols, the code directly references
their address. Can you name one tool that will easily remove such
"aggregated" code from the kernel image? And we aren't just talking
about firmware here. There are header files and even C source files
with issues in the vanilla kernel.

I agree with you that firmware included in a kernel deb that gets
loaded with the firmware loader just an aggregation. But that is not
the issue here.

And even for an aggregation of works the DFSG holds and you are still
in trouble.


Let me make another example. I take a GPL program and link in a
non-free library plus glue code that forks a child and uses the
library. Only the child does use the non-free library and the
communication between father and child is clearly defined.

The non-free library never runs in the same address space as the rest
of the program. Does that mean this is just an aggregation of works
and GPL compliant?

If I put the non-free library into an external plugin and (optionaly)
dlopen it then I have a completly different story.

> The second case is easier, we have simply to remove the non-free firmware, and
> put it in non-free, and/or remove completely the non-free driver and put it in
> non-free. In the case of modules vital to boot the machine we are trully
> screwed here, and by some of ourselves even.
>
> The problem is that the installer people, who where told repeteadly by me and
> others about this issue since over 6 month, and should have worked on enabling
> the installer to load .udebs from multiple apt/anna sources and not just one,
> thus enabling to place those non-free .udebs into a separate non-free .udeb
> archive, and solve this problem neatly.

I've been bugging Bastian about this issue as well since I need this for
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.

> But then, the d-i team, has prefered to ignore this issue, shot the messenger,
> and go into kicking out, witch hunts and diffamatory tactics in order to not
> face their own lack of vision and inadequateness, in the same way as their
> reaction to the kernel module .udeb proposal was over-agressive and now leaves
> us in mostly the same situation as we where at the sarge release time, with
> the d-i team incapacity to handle kernel abi bumps and security upgrades in a
> timely fashion.

One problem is that you keep banging on the door, where the watchdog
barks at you and the armed guards won't let you in. Try the window or
the backdoor. Change your approach.

Personaly I think the only way to get D-I to use non-free udebs is to
first have some. Preferably something essential. The harddisk driver
or network driver of Bastians or Joeys system would be perfect. Since
we can't convince the developer to implement this feature for its own
merit lets create some desperate need for it.

> So, i don't believe there is much choice left to the kernel team in this issue
> but to ask for a waiver of the DFSG compliance for the kernel for etch, and
> hope the d-i folk take their responsabilities a bit more seriously for the
> etch+1 release.

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

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Gnu-Raiz]

On Monday 07 August 2006 03:23, Frederik Schueler wrote:
> Hello,
>
> On Mon, Aug 07, 2006 at 09:32:11AM +0200, Sven Luther wrote:
> > These are fine words, but how do you think they can translate
> > into reality ? We don't currently have the ressources to do it
> > the way it should be done, and evne if we did, the deficiencies
> > of d-i will make the work we do useless.
>
> Sven, can you please finally STOP flaming against the
> debian-installer team, thank you.
>
> > But then, you could help, and put your actions where your mouth
> > is, by helping in the elaboration of an exhaustive list of such
> > problematic firmware hexdumps, together with their licencing
> > conditions, their copyright holder, and a summary of what the
> > module is good for.
>
> I agree, everyone who wants to see the firmware issue solved
> should either start doing something about it or be silent.
>
> here is an outdated wiki document, where to start with:
>
> http://wiki.debian.org/KernelFirmwareLicensing
>
>
> Best regards
> Frederik Schueler

I have been following this list for some time, and have seen the 
egos on both sides get out of hand. But to me this shows the lack 
of maturity and refelects back to grade school. We are all adults 
here so what if someone has an opinion about how something was done 
or should be done. All you have to do is read a few slashdot 
articles, GET OVER IT.  We should be focusing on fixing release 
critical bugs, or learing how to code better. Calling the kettle 
black is not helpful, and takes up time that should be used for 
something else. 

Telling someone to stop flamming is like bringing up attention to 
something that probably was not even be an issue, now it has become 
an issue because of some issues in the past. This is the time to 
let your professional attitude come out, if you have personal 
issues with a topic or person hold your tongue, and listen for 
once. If you cant then send a flame email to me, if it makes you 
fell better my feelings won't be hurt. 

This is also a good time to take the high road, and leave the past 
in the past, maybe we all need to take some communication classes. 
I bet a lot of this anger could be vented if we just listen and 
acknowledge the differences and try to understand the others point 
of view. You will be surprised to know that once someone has vented 
his thoughts without anger, and listened then things would be 
better. Maybe we need to eat a little crow, and admit we are wrong 
get on with making Debian the best possible distro their is.

Gnu_Raiz


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Marco d'Itri]

On Aug 07, Goswin von Brederlow <[EMAIL PROTECTED]> wrote:

> > No, because those are not linked together with the GPLed code, but are a 
> > mere
> > aggregation of works inside the same media, i.e. the binary file. Those
> > non-free firmware will never run inside the same memory space as the kernel,
> > and are offloaded to a peripheral processor, and the communication media
> > between the kernel and this peripheral processor running said firmware is
> > clearly defined, there is no doubt that those non-free firmware do not break
> > the kernel GPL.

> They are linked in, they have symbols, the code directly references
> their address. Can you name one tool that will easily remove such
No. They are a char array, it's data copied where the hardware wants it.
It's not code called by other functions.

> "aggregated" code from the kernel image?
Not relevant.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Sven Luther]

On Mon, Aug 07, 2006 at 02:48:08PM +0200, Goswin von Brederlow wrote:
> Sven Luther <[EMAIL PROTECTED]> writes:
> 
> > On Sun, Aug 06, 2006 at 01:21:32PM +0200, Goswin von Brederlow wrote:
> >> [EMAIL PROTECTED] (Marco d'Itri) writes:
> >> 
> >> > On Aug 04, Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
> >> >
> >> >> >>think not?  Prove it by proposing a GR.  More importantly, the 
> >> >> >>release team
> >> >> > I had such a plan, but no time to implement it currently.
> >> >> How do you handle the fact that it is a license violation making the
> >> >> thing illegal to distribute?
> >> > I see that the lawyers of SuSE and Red Hat do not believe this to be
> >> > true or at least do not consider it a problem, and this is enough for
> >> > me to ignore the opinion of the debian-legal@ armchair lawyers.
> >> >
> >> > -- 
> >> > ciao,
> >> > Marco
> >> 
> >> I hope you do believe this to be true. Otherwise you would need to go
> >> back to NM and do the licensing section again. There can be no doubt
> >> that binaries without source or even a "DO NOT DISTRIBUTE" notice
> >> break the GPL.
> >
> > No, because those are not linked together with the GPLed code, but are a 
> > mere
> > aggregation of works inside the same media, i.e. the binary file. Those
> > non-free firmware will never run inside the same memory space as the kernel,
> > and are offloaded to a peripheral processor, and the communication media
> > between the kernel and this peripheral processor running said firmware is
> > clearly defined, there is no doubt that those non-free firmware do not break
> > the kernel GPL.
> 
> They are linked in, they have symbols, the code directly references
> their address. Can you name one tool that will easily remove such

i guess objdump would do it, from most of these cases, the only symbol
involved is the position of it in the code, and the incrimated code is just a
binary hexdump contained in a single variable + size.

> "aggregated" code from the kernel image? And we aren't just talking
> about firmware here. There are header files and even C source files
> with issues in the vanilla kernel.

Well, we are speaking about "firmware hexdumps", i don't know about the others
you are referencing, but if there are other suchs, please list them
explicitly. And no, a separate header file containing just this single
variable doesn't count.

> I agree with you that firmware included in a kernel deb that gets
> loaded with the firmware loader just an aggregation. But that is not
> the issue here.

What is then ? 

> And even for an aggregation of works the DFSG holds and you are still
> in trouble.

Sure, the DFSG says that we need the source code for those, and they are thus
non-free, but what i am arguing is that they are not violation of the kernel
GPL, since they are separate aggregate works.

> Let me make another example. I take a GPL program and link in a
> non-free library plus glue code that forks a child and uses the
> library. Only the child does use the non-free library and the
> communication between father and child is clearly defined.

Let me make another example. You buy a random bunch of hardware, and either
run linux on it, or run a free linux driver running it. This hardware in
question happens to have some random bios on it, which is non-free, or some
fpga config file hidden in a flash.

This is exactly the same case as the one you are describing, with the sole
exception of the firmware in question being temporarily transported in the
kernel binary and uploaded in the device.

If you follow the FSF FAQ about the GPL, you will see that there are a certain
amount of criterias which apply here, among them the separate memory pool/area
one, as well as the well defined communication interface, which is clearly
respected here. 

So, altough IANAL, i believe without doubts that we are not seing a GPL
violation here, and that the non-free firmware and the linux kernel are mere
aggregation. After writing this to LKML last year, i also contacted the FSF
legal counsel, and altough they didn't give a supportive analysis of this,
there was no strong outcry either. Not sure what this means.

I believe i got the consensus of debian-legal behind me on this one, as you
would see if you consulted the archives, and the broadcom, and QL-something,
legal team, also found this analysis reasonable and changed their tg3 and
ql-something licencing accordyingly.

Also, if you really want to argue the other way, you will end up in a world of
trouble, and will end not being able to run linux on any box around i know.

Finally, what you mention is more akin to the unicorn driver, which is a
driver for a soft-ADSL pci modem, which links to a non-free, binary-only,
x86-only ADSL library. This is indeed more than just agregation, and after i
engaged bewan over it, and we consulted with RMS and the FSF, they released
their drivers with a GPL+exception licence, and the package is now happily
sitting in non-free, waiting for so

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Sven Luther]

On Mon, Aug 07, 2006 at 04:53:51PM +0200, Marco d'Itri wrote:
> On Aug 07, Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
> 
> > > No, because those are not linked together with the GPLed code, but are a 
> > > mere
> > > aggregation of works inside the same media, i.e. the binary file. Those
> > > non-free firmware will never run inside the same memory space as the 
> > > kernel,
> > > and are offloaded to a peripheral processor, and the communication media
> > > between the kernel and this peripheral processor running said firmware is
> > > clearly defined, there is no doubt that those non-free firmware do not 
> > > break
> > > the kernel GPL.
> 
> > They are linked in, they have symbols, the code directly references
> > their address. Can you name one tool that will easily remove such
> No. They are a char array, it's data copied where the hardware wants it.
> It's not code called by other functions.

Yeah, exact, its mips or arm machine code, uploaded to the embedded core in
the chip used for the peripheral in question.

Err, you probably have a very different definition of code than me, or maybe
you have absolutely no clue about how hardware works, which is sincerely
doubt.

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Thiemo Seufer]

Sven Luther wrote:
> On Mon, Aug 07, 2006 at 04:53:51PM +0200, Marco d'Itri wrote:
> > On Aug 07, Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
> > 
> > > > No, because those are not linked together with the GPLed code, but are 
> > > > a mere
> > > > aggregation of works inside the same media, i.e. the binary file. Those
> > > > non-free firmware will never run inside the same memory space as the 
> > > > kernel,
> > > > and are offloaded to a peripheral processor, and the communication media
> > > > between the kernel and this peripheral processor running said firmware 
> > > > is
> > > > clearly defined, there is no doubt that those non-free firmware do not 
> > > > break
> > > > the kernel GPL.
> > 
> > > They are linked in, they have symbols, the code directly references
> > > their address. Can you name one tool that will easily remove such
> > No. They are a char array, it's data copied where the hardware wants it.
> > It's not code called by other functions.
> 
> Yeah, exact, its mips or arm machine code, uploaded to the embedded core in
> the chip used for the peripheral in question.

Often it isn't, unless you want to call the content of a configuration
register bank "code".


Thiemo


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Sven Luther]

On Mon, Aug 07, 2006 at 06:24:12PM +0100, Thiemo Seufer wrote:
> Sven Luther wrote:
> > On Mon, Aug 07, 2006 at 04:53:51PM +0200, Marco d'Itri wrote:
> > > On Aug 07, Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
> > > 
> > > > > No, because those are not linked together with the GPLed code, but 
> > > > > are a mere
> > > > > aggregation of works inside the same media, i.e. the binary file. 
> > > > > Those
> > > > > non-free firmware will never run inside the same memory space as the 
> > > > > kernel,
> > > > > and are offloaded to a peripheral processor, and the communication 
> > > > > media
> > > > > between the kernel and this peripheral processor running said 
> > > > > firmware is
> > > > > clearly defined, there is no doubt that those non-free firmware do 
> > > > > not break
> > > > > the kernel GPL.
> > > 
> > > > They are linked in, they have symbols, the code directly references
> > > > their address. Can you name one tool that will easily remove such
> > > No. They are a char array, it's data copied where the hardware wants it.
> > > It's not code called by other functions.
> > 
> > Yeah, exact, its mips or arm machine code, uploaded to the embedded core in
> > the chip used for the peripheral in question.
> 
> Often it isn't, unless you want to call the content of a configuration
> register bank "code".

Given that the specs of most of those chips are not available except under
NDA, how would you make the difference ? And even then, once could consider
that the definition of those registers are kind of part of the source to said
"code".

But if you feel like it, go ahead, and provide us with the extensive list of
all those cases, and provide evidence in how those firmware blobs are only
register dumps, and then we can indeed let some of those in main. At least we
would probably need the format of the register dump in question though.

Also, this then has implications on the miboot boot sector, which is currently
not even allowed in non-free, since there is no clear licencing about it, and
apple doesn't care about decades old code.

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Thomas Bushnell BSG]

Sven Luther <[EMAIL PROTECTED]> writes:

> untruth in what i said above, or in the other mail ? 

Yes.  There is the option of simply not supporting installation on the
devices in question.

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Marco d'Itri]

On Aug 08, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote:

> Yes.  There is the option of simply not supporting installation on the
> devices in question.
i.e. screwing our users.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Thomas Bushnell BSG]

[EMAIL PROTECTED] (Marco d'Itri) writes:

> On Aug 08, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote:
>
>> Yes.  There is the option of simply not supporting installation on the
>> devices in question.

> i.e. screwing our users.

We Do Not Distribute Non-Free Software No Matter How Much It Helps Our
Users.

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Marco d'Itri]

On Aug 08, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote:

> We Do Not Distribute Non-Free Software No Matter How Much It Helps Our
> Users.
Now think about why we do not do it.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Thomas Bushnell BSG]

[EMAIL PROTECTED] (Marco d'Itri) writes:

> On Aug 08, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote:
>
>> We Do Not Distribute Non-Free Software No Matter How Much It Helps Our
>> Users.

> Now think about why we do not do it.

It does not matter.  Different members of Debian have different
reasons.  We have all agreed to work together on the basis of the
Social Contract, which says that We Do Not Distribute Non-Free
Software No Matter How Much It Helps Our Users.

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Marco d'Itri]

On Aug 08, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote:

> > Now think about why we do not do it.
> It does not matter.  Different members of Debian have different
> reasons.  We have all agreed to work together on the basis of the
> Social Contract, which says that We Do Not Distribute Non-Free
> Software No Matter How Much It Helps Our Users.
I rest my case.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Thomas Bushnell BSG]

[EMAIL PROTECTED] (Marco d'Itri) writes:

> On Aug 08, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote:
>
>> > Now think about why we do not do it.
>> It does not matter.  Different members of Debian have different
>> reasons.  We have all agreed to work together on the basis of the
>> Social Contract, which says that We Do Not Distribute Non-Free
>> Software No Matter How Much It Helps Our Users.

> I rest my case.

Your case that... what?

That our users will be inconvenienced if we cannot support certain
hardware in the installer?  Yes, nobody has doubted this.

But you have not given any argument for why this should in this one
case override our principles, cause us to violate our own Social
Contract, and otherwise simply abandon what Debian stands for.

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Sven Luther]

On Mon, Aug 07, 2006 at 04:26:45PM -0700, Thomas Bushnell BSG wrote:
> Sven Luther <[EMAIL PROTECTED]> writes:
> 
> > untruth in what i said above, or in the other mail ? 
> 
> Yes.  There is the option of simply not supporting installation on the
> devices in question.

Yeah, well, sure there is, but given what those devices are, and the general
outcry when we temporarily removed them in the past, i have some serious
doubts about this really being a solution. But then, we where speaking
about the 'inflamatory' part of those mails, not about the more technical
part.

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Sven Luther]

On Mon, Aug 07, 2006 at 04:46:09PM -0700, Thomas Bushnell BSG wrote:
> [EMAIL PROTECTED] (Marco d'Itri) writes:
> 
> > On Aug 08, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote:
> >
> >> We Do Not Distribute Non-Free Software No Matter How Much It Helps Our
> >> Users.
> 
> > Now think about why we do not do it.
> 
> It does not matter.  Different members of Debian have different
> reasons.  We have all agreed to work together on the basis of the
> Social Contract, which says that We Do Not Distribute Non-Free
> Software No Matter How Much It Helps Our Users.

  # Our priorities are our users and free software

  We will be guided by the needs of our users and the free software community.
  We will place their interests first in our priorities. We will support the
  needs of our users for operation in many different kinds of computing
  environments. We will not object to non-free works that are intended to be
  used on Debian systems, or attempt to charge a fee to people who create or
  use such works. We will allow others to create distributions containing both
  the Debian system and other works, without any fee from us. In furtherance
  of these goals, we will provide an integrated system of high-quality
  materials with no legal restrictions that would prevent such uses of the
  system.

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Mike Hommey]

On Tue, Aug 08, 2006 at 06:49:32AM +0200, Sven Luther <[EMAIL PROTECTED]> wrote:
> On Mon, Aug 07, 2006 at 04:46:09PM -0700, Thomas Bushnell BSG wrote:
> > [EMAIL PROTECTED] (Marco d'Itri) writes:
> > 
> > > On Aug 08, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote:
> > >
> > >> We Do Not Distribute Non-Free Software No Matter How Much It Helps Our
> > >> Users.
> > 
> > > Now think about why we do not do it.
> > 
> > It does not matter.  Different members of Debian have different
> > reasons.  We have all agreed to work together on the basis of the
> > Social Contract, which says that We Do Not Distribute Non-Free
> > Software No Matter How Much It Helps Our Users.
> 
>   # Our priorities are our users and free software
> 
>   We will be guided by the needs of our users and the free software community.
>   We will place their interests first in our priorities. We will support the
>   needs of our users for operation in many different kinds of computing
>   environments. We will not object to non-free works that are intended to be
>   used on Debian systems, or attempt to charge a fee to people who create or
>   use such works. We will allow others to create distributions containing both
>   the Debian system and other works, without any fee from us. In furtherance
>   of these goals, we will provide an integrated system of high-quality
>   materials with no legal restrictions that would prevent such uses of the
>   system.

Where do you read we allow ourselves to distribute non-free software for
user convenience ?

Mike


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Sven Luther]

On Tue, Aug 08, 2006 at 07:39:21AM +0200, Mike Hommey wrote:
> On Tue, Aug 08, 2006 at 06:49:32AM +0200, Sven Luther <[EMAIL PROTECTED]> 
> wrote:
> > On Mon, Aug 07, 2006 at 04:46:09PM -0700, Thomas Bushnell BSG wrote:
> > > [EMAIL PROTECTED] (Marco d'Itri) writes:
> > > 
> > > > On Aug 08, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote:
> > > >
> > > >> We Do Not Distribute Non-Free Software No Matter How Much It Helps Our
> > > >> Users.
> > > 
> > > > Now think about why we do not do it.
> > > 
> > > It does not matter.  Different members of Debian have different
> > > reasons.  We have all agreed to work together on the basis of the
> > > Social Contract, which says that We Do Not Distribute Non-Free
> > > Software No Matter How Much It Helps Our Users.
> > 
> >   # Our priorities are our users and free software
> > 
> >   We will be guided by the needs of our users and the free software 
> > community.
> >   We will place their interests first in our priorities. We will support the
> >   needs of our users for operation in many different kinds of computing
> >   environments. We will not object to non-free works that are intended to be
> >   used on Debian systems, or attempt to charge a fee to people who create or
> >   use such works. We will allow others to create distributions containing 
> > both
> >   the Debian system and other works, without any fee from us. In furtherance
> >   of these goals, we will provide an integrated system of high-quality
> >   materials with no legal restrictions that would prevent such uses of the
> >   system.
> 
> Where do you read we allow ourselves to distribute non-free software for
> user convenience ?

Well, it reads to me that we won't screw our users without second thought like 
some
here are proposing.

But then, i repeat, everyone is very welcome to participate in solving this
the nice way, and i am highly impatient to see the extensive listings you and
others may produce, and then some plan on how to go forward from there.

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Thomas Bushnell BSG]

Sven Luther <[EMAIL PROTECTED]> writes:

>   # Our priorities are our users and free software
>
>   We will be guided by the needs of our users and the free software community.
>   We will place their interests first in our priorities. We will support the
>   needs of our users for operation in many different kinds of computing
>   environments. We will not object to non-free works that are intended to be
>   used on Debian systems, or attempt to charge a fee to people who create or
>   use such works. We will allow others to create distributions containing both
>   the Debian system and other works, without any fee from us. In furtherance
>   of these goals, we will provide an integrated system of high-quality
>   materials with no legal restrictions that would prevent such uses of the
>   system.

Nothing here says that when we have no way to support a user's task
with free software, we will go ahead and ship nonfree software to do
this.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Thomas Bushnell BSG]

Sven Luther <[EMAIL PROTECTED]> writes:

> Well, it reads to me that we won't screw our users without second
> thought like some here are proposing.

In my opinion, we have been screwing our users for years by lying to
them about whether their software was free.  We would even say things
like "hardware such-and-such is supportable with free software" and
then ship them a non-free driver.

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Jim Crilly]

On 08/08/06 04:49:33PM -0700, Thomas Bushnell BSG wrote:
> Sven Luther <[EMAIL PROTECTED]> writes:
> 
> > Well, it reads to me that we won't screw our users without second
> > thought like some here are proposing.
> 
> In my opinion, we have been screwing our users for years by lying to
> them about whether their software was free.  We would even say things
> like "hardware such-and-such is supportable with free software" and
> then ship them a non-free driver.
> 

I'm sure this has been suggested/covered before, but what's wrong with just
sticking those drivers in non-free and giving the user a choice during
installation? Sure, it'll screw the users that won't have Internet access
during the installation, but as long as it's possible to make custom
installation discs that'll probably take care of itself.

Jim.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Sven Luther]

On Tue, Aug 08, 2006 at 04:49:33PM -0700, Thomas Bushnell BSG wrote:
> Sven Luther <[EMAIL PROTECTED]> writes:
> 
> > Well, it reads to me that we won't screw our users without second
> > thought like some here are proposing.
> 
> In my opinion, we have been screwing our users for years by lying to
> them about whether their software was free.  We would even say things
> like "hardware such-and-such is supportable with free software" and
> then ship them a non-free driver.

Well, its a different sort of screwing.

But then my position on this has always been to be clear, and say things
plainly as they are, and not like others or other distribs or upstream to
ignore the issue and hope it does go  away.

At this point we have those possible choices :

  1) move the kernel to non-free, and be done with it.

  2) either move the individual affected drivers or just their firmware if
  possible to non-free, and keep the cripled kernel in main.

  3) reverse-engineer and reimplement those firmwares, or convince upstream to
  free them.

  4) pass a GR explaining the issue as is, and admitting our incapacity to fix
  it with 2 or 3 due to lack of ressources.

3) would be nicest, but it is a never ending task, and we can't do it. We
could do 2), but even this will mean some serious work and possibly a delay of
the etch release schedule, especially as we don't have a full audit of what
files are exactly affected. 2) (and 1) also mean the cooperation of the d-i
team, which we have not been getting on this so far, all to the contrary,
since they need to fix d-i to load more than one apt source, and since the d-i
folk probably consider the etch d-i as frozen right now, ...

So, this leaves us what, as reasonable solution for etch ? 1 and 4, and 1 will
be too disruptive, so only 4 is left.

It is not as if the issue is new though, we have been knowing about this since
almost a year, and many voiced their concern or support at various time, but
actual help was few and far between (partly our fault in one case though at
least).

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Sven Luther]

On Tue, Aug 08, 2006 at 08:12:48PM -0400, Jim Crilly wrote:
> On 08/08/06 04:49:33PM -0700, Thomas Bushnell BSG wrote:
> > Sven Luther <[EMAIL PROTECTED]> writes:
> > 
> > > Well, it reads to me that we won't screw our users without second
> > > thought like some here are proposing.
> > 
> > In my opinion, we have been screwing our users for years by lying to
> > them about whether their software was free.  We would even say things
> > like "hardware such-and-such is supportable with free software" and
> > then ship them a non-free driver.
> > 
> 
> I'm sure this has been suggested/covered before, but what's wrong with just
> sticking those drivers in non-free and giving the user a choice during

Well, i mentioned this already elsewhere in this thread, but there you go :

  1) it is lot of work, and we (the kernel team) don't realy have the ressources
  for it. 

  2) there is currently no exhaustive list of affected drivers, there may even
  be some case of things like main processor micro-code affected.

  3) it demands works of part of debian outside the kernel team, particularly
  the d-i and eventually archive folk. The d-i have not been cooperative to
  this idea, and even mentioning it to them has resulted in a barrage of
  agresive bashing. But then maybe it was just because they don't like me and
  i dared to mention this all those months back. In any case, they have not
  fixed their side of it, and there appears to be no plan to do so, i was
  kicked out of the d-i project, and Frans threatened me if i even dared work
  on kernel/d-i based issues.

> installation? Sure, it'll screw the users that won't have Internet access
> during the installation, but as long as it's possible to make custom
> installation discs that'll probably take care of itself.

You can do a CD media which includes the non-free modules, you would have to
build a non-free d-i image set anyway.

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Thomas Bushnell BSG]

Sven Luther <[EMAIL PROTECTED]> writes:

>   2) either move the individual affected drivers or just their firmware if
>   possible to non-free, and keep the cripled kernel in main.

This is certainly the last resort, in my opinion, but it isn't
"crippled".  Merely not supporting particular pieces of hardware, in a
world in which Linux *already* fails to support lots of popular
hardware, is not a disaster.  It's a shame, and we should avoid it if
we can, but it's a shame.

> 3) would be nicest, but it is a never ending task, and we can't do
> it. We could do 2), but even this will mean some serious work and
> possibly a delay of the etch release schedule, especially as we
> don't have a full audit of what files are exactly affected. 

Life is rough.  The kernel team has had *ample* warning, since it was
midway through *sarge* that the rules became clear.

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Thomas Bushnell BSG]

Sven Luther <[EMAIL PROTECTED]> writes:

>   4) pass a GR explaining the issue as is, and admitting our
>   incapacity to fix it with 2 or 3 due to lack of ressources.

We do not need a GR to simply follow our existing procedures.  

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Sven Luther]

On Wed, Aug 09, 2006 at 12:57:36AM -0700, Thomas Bushnell BSG wrote:
> Sven Luther <[EMAIL PROTECTED]> writes:
> 
> >   2) either move the individual affected drivers or just their firmware if
> >   possible to non-free, and keep the cripled kernel in main.
> 
> This is certainly the last resort, in my opinion, but it isn't
> "crippled".  Merely not supporting particular pieces of hardware, in a
> world in which Linux *already* fails to support lots of popular
> hardware, is not a disaster.  It's a shame, and we should avoid it if
> we can, but it's a shame.
> 
> > 3) would be nicest, but it is a never ending task, and we can't do
> > it. We could do 2), but even this will mean some serious work and
> > possibly a delay of the etch release schedule, especially as we
> > don't have a full audit of what files are exactly affected. 
> 
> Life is rough.  The kernel team has had *ample* warning, since it was
> midway through *sarge* that the rules became clear.

Nope, the issue only surfaced early after the sarge release, a bit less than a
year ago, when the new kernel team formed. 

Now, this is a long term *UPSTREAM* kind of work, and we simply don't have the
ressources of undertaking it.

As for me, i have been bogged down into defending against the multiple
tentatives to get ride of me since early marsh, and could thus produce no
useful work of this nature during this time, Andres Salomon left because his
tentative of exclusion of me from debian failed, others have been assortedly
busy too.

And it is not as if *YOU* had not ample warning about the ressource problems,
since we mentioned the lack of manpower and ressources regularly since a
almost as long as the issue surfaced. And this is not really a work which can
be done without diverting ressources from normal maintenance work, which would
be detrimental.

So, basically, you are criticizing the kernel team for not having devoted
enough of their *volunteer* time to this issue, and at the same time you
expect us to provide good quality kernel packages to debian ? 

Well, again, the offer is open, and i already multiple times proposed those
like you to start helping and providing an exhaustive list of those files
which are involved, as well as a basic classification of the nature of their
problem. This is assuredly within the reach of each debian maintainer or
associated, and doesn't need any particular kernel-coding skill, but some
legal/licencing knowledge.

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Sven Luther]

On Wed, Aug 09, 2006 at 12:58:33AM -0700, Thomas Bushnell BSG wrote:
> Sven Luther <[EMAIL PROTECTED]> writes:
> 
> >   4) pass a GR explaining the issue as is, and admitting our
> >   incapacity to fix it with 2 or 3 due to lack of ressources.
> 
> We do not need a GR to simply follow our existing procedures.  

Sure, we do, because wehad a pre-sarge GR, which allowed to ignore the
firmware (and other issues), but only for the sarge release, remember ? 

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Thomas Bushnell BSG]

Sven Luther <[EMAIL PROTECTED]> writes:

> Nope, the issue only surfaced early after the sarge release, a bit
> less than a year ago, when the new kernel team formed.

It was discussed *before* sarge was released that there was non-free
firmware in the kernel, and we decided to ignore it for the sarge
release.  We explicitly did *not* decide to ignore it forever.

> So, basically, you are criticizing the kernel team for not having devoted
> enough of their *volunteer* time to this issue, and at the same time you
> expect us to provide good quality kernel packages to debian ? 

No.  I would be content with a "we don't support that hardware"
decision, though it would be less than the best thing.

I'm willing to wait for this work to be finished before etch is
released.

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Thomas Bushnell BSG]

Sven Luther <[EMAIL PROTECTED]> writes:

> On Wed, Aug 09, 2006 at 12:58:33AM -0700, Thomas Bushnell BSG wrote:
>> Sven Luther <[EMAIL PROTECTED]> writes:
>> 
>> >   4) pass a GR explaining the issue as is, and admitting our
>> >   incapacity to fix it with 2 or 3 due to lack of ressources.
>> 
>> We do not need a GR to simply follow our existing procedures.  
>
> Sure, we do, because wehad a pre-sarge GR, which allowed to ignore the
> firmware (and other issues), but only for the sarge release, remember ? 

We can simply take our time to do (2).  It is the job of a package
maintainer to check the licenses of their software; if the kernel team
cannot do so by December, even with help, I don't mind waiting.

However, what started this thread IIRC was a complaint that the kernel
team was *closing* the relevant bugs.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Sven Luther]

On Wed, Aug 09, 2006 at 02:02:42AM -0700, Thomas Bushnell BSG wrote:
> Sven Luther <[EMAIL PROTECTED]> writes:
> 
> > On Wed, Aug 09, 2006 at 12:58:33AM -0700, Thomas Bushnell BSG wrote:
> >> Sven Luther <[EMAIL PROTECTED]> writes:
> >> 
> >> >   4) pass a GR explaining the issue as is, and admitting our
> >> >   incapacity to fix it with 2 or 3 due to lack of ressources.
> >> 
> >> We do not need a GR to simply follow our existing procedures.  
> >
> > Sure, we do, because wehad a pre-sarge GR, which allowed to ignore the
> > firmware (and other issues), but only for the sarge release, remember ? 
> 
> We can simply take our time to do (2).  It is the job of a package
> maintainer to check the licenses of their software; if the kernel team
> cannot do so by December, even with help, I don't mind waiting.

Well, the question is if we can release etch in this state or not. Given the
previous GR wording, this is not the case, and we either delay etch for a long
time, or provide an override.

> However, what started this thread IIRC was a complaint that the kernel
> team was *closing* the relevant bugs.

Well, i may not have followed the start of it, but it is something that both
the RM team as the kernel team are aware of, even if some individual members
may prefer to keep the status quo or ignore the issue.

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Sven Luther]

On Wed, Aug 09, 2006 at 02:01:33AM -0700, Thomas Bushnell BSG wrote:
> Sven Luther <[EMAIL PROTECTED]> writes:
> 
> > Nope, the issue only surfaced early after the sarge release, a bit
> > less than a year ago, when the new kernel team formed.
> 
> It was discussed *before* sarge was released that there was non-free
> firmware in the kernel, and we decided to ignore it for the sarge
> release.  We explicitly did *not* decide to ignore it forever.

Maybe, but the kernel team was really operational, and not saddled with broken
legacy packaging only after the sarge release.

> > So, basically, you are criticizing the kernel team for not having devoted
> > enough of their *volunteer* time to this issue, and at the same time you
> > expect us to provide good quality kernel packages to debian ? 
> 
> No.  I would be content with a "we don't support that hardware"
> decision, though it would be less than the best thing.
> 
> I'm willing to wait for this work to be finished before etch is
> released.

Yep, but the question is, are the rest of the DDs willing to wait too ? This
is best answered by a GR, not sure if it needs 3:1 supermajority or not, i
think if it is only a delay-it-once-more, it does not need that, contrary to a
changing of the wording of the social contract would be.

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Frederik Schueler]

Hallo,

On Wed, Aug 09, 2006 at 02:02:42AM -0700, Thomas Bushnell BSG wrote:
> We can simply take our time to do (2).  It is the job of a package
> maintainer to check the licenses of their software; if the kernel team
> cannot do so by December, even with help, I don't mind waiting.

then, please, send patches.


Best regards
Frederik Schueler

-- 
ENOSIG


signature.asc
Description: Digital signature

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Jeff Carr]

On 08/02/06 22:17, Nathanael Nerode wrote:

> Start with drivers/char/drm/mga_ucode.h.  This is distributable, because it's 
> under
> a BSD license, but it's not free software, because there's no source code.

There is no source code, because there never was any source code.

What do you think should be done if source code doesn't make sense or
can't be made?

Jeff


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Nathanael Nerode]

[EMAIL PROTECTED] wrote:
On 08/02/06 22:17, Nathanael Nerode wrote:

>> Start with drivers/char/drm/mga_ucode.h.  This is distributable, because 
>> it's under
>> a BSD license, but it's not free software, because there's no source code.
>There is no source code, because there never was any source code.

Do you have *actual evidence* of this?  Are you a Matrox employee?  Do you have 
an email from one?  Do you know the "microcode" format and can you explain how 
to easily edit the hex to make the microcode do different things?

If any of the above, please provide your evidence.  If the microcode was 
wriiten in hex, hex is the sorurce code and we can include it.

Otherwise, I contend that you are just making this up and Matrox actually has 
source code which it is withholding.  Replies to debian-kernel please.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Nathanael Nerode]

I apologize for responding to Marco's post; in retrospect he was clearly
trolling and I should not have responded to him.

The point of my initial message was not to argue: it was that the etch
timeline is unrealistic, because I see no progress on removing the
substantial number of sourceless binaries from the Linux kernel source
package, and it's *after* the kernel was supposed to have frozen!

Is there a plan for dealing with this fast enough to avoid delaying the
release of etch?  If so, please post it.

If not, I suggest the following process improvements:

For each driver containing a sourceless binary, someone (probably me) will
file a single bug against the source package linux-2.6.  Currently there is
a single bug (242866/243022) covering multiple issues,  against 'kernel',
which is a pseudo-package.  Looking at the list of antique bugs
against 'kernel', I don't think anyone is reading them.  Also, with the
planned removal of
pre-2.6 kernel packages, a bug against linux-2.6 seems sufficient to cover
everything.

Why one bug per driver?   Because each driver's bug is slightly different
and I expect each to be fixed in a slightly different way.  Some bugs are
distributability issues, while some are clearly distributable and simply
non-free.  Some may be fixed by a new upstream version.  Some may be fixed
by implementing firmware loading and a non-free firmware package; some may
be fixed by moving the driver to an out-of-tree kernel module; others may
be fixed by removing the driver entirely; others (where the firmware is
unimportant) may be fixed by removing the firmware and the support for
whatever feature it enables.  In the case of the DRM modules, the result
may depend on the implementation of features in X, and bugs may block on
that.  The point is that each case is going to be different.  The progress
on the different drivers is already different.

This should make tracking the issues significantly clearer: specifically it
will make it clear exactly what needs to be done to fix this.  It would
also make it look a bit less like an infinite tentacled monster, perhaps
making it easier for people to bite off one bug at a time.  (Certainly I
get confused posting fixes for different drivers to the same bug.)  We
would then convert 242866 to a meta-bug blocking on each individual bug.

How does that sound?

http://wiki.debian.org/KernelFirmwareLicensing is grossly out-of-date, but I
will integrate the relevant information from that in the process.

Alternative option: the Wiki page could be revived and used to coordinate
the process.  Unfortunately it's quite out-of-date, and it's unwieldly.  I
prefer the BTS option because it's more permanent, harder to ignore, and
better at holding patches and whatnot.

-- 
Nathanael Nerode  <[EMAIL PROTECTED]>

Bush admitted to violating FISA and said he was proud of it.
So why isn't he in prison yet?...


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Sven Luther]

On Sat, Aug 05, 2006 at 11:29:44PM -0400, Nathanael Nerode wrote:
> I apologize for responding to Marco's post; in retrospect he was clearly
> trolling and I should not have responded to him.
> 
> The point of my initial message was not to argue: it was that the etch
> timeline is unrealistic, because I see no progress on removing the
> substantial number of sourceless binaries from the Linux kernel source
> package, and it's *after* the kernel was supposed to have frozen!
> 
> Is there a plan for dealing with this fast enough to avoid delaying the
> release of etch?  If so, please post it.

Well, there is no way i see that we can deal with this in a timely fashion
without delaying etch by a year or so. Remember that d-i and kernel freeze
date was planned last week.

Furthermore, there is no evidence that future upstream version of the kernel
will not add more such non-free firmware, so this would be an ongoing process,
and we also have to keep in sync with the upstream efforts to do so.

As thus, i think the more reasonable way to handle this, is to not force this
to be solved for etch, but let etch be released as is (needs a GR though, but
not a 3:1 one), while at the same time start a coordinated process to solve
the issue, which would probably be something akin to a never ending work,
until upstream uses the no-non-free-firmware policy also.



So, the real solution to this would be to setup a, maybe separate, team of
folk working on the non-free firmware issue, and proposing patches, patches
which have a chance to be merged upstream, to solve this issue. This could
overlap with the kernel team, or not, but the patches need to be approved by
the kernel team, and forwarded upstream. The kernel team as is should continue
focusing on packaging issues and normal maintenance.

Now, on how to go forward with this issue, i think the most reasonable way
would be for someone caring about the issue (you ?) to take ownership of the
wiki page (maybe saving the current content in another page), and start with
an exhaustive list, as well as analysis of each individual case. This would be
preferable to a bug filing tactic, which would just be lost in the huge load
of kernel bug reports anyway, and be more constructive. Maybe open a single
bug pointing to said wiki page or something.

Once that is done, the real work can start. Notice that the situation has
clearly improved upstream with relation to the patches you sent a couple of
year back, and which apparently somehow broke the drivers, so now would be a
good time to restart that effort.

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Thiemo Seufer]

Nathanael Nerode wrote:
[snip]
> http://wiki.debian.org/KernelFirmwareLicensing is grossly out-of-date, but I
> will integrate the relevant information from that in the process.

KernelFirmwareLicensing is supposed to track information about
mis-licensed firmware. IIRC you mentioned to have found at least one
such driver in the Debian kernel, if that's correct, please update
the wiki with that information.

Please don't use KernelFirmwareLicensing for correctly licensed
firmware.

> Alternative option: the Wiki page could be revived and used to coordinate
> the process.  Unfortunately it's quite out-of-date, and it's unwieldly.

You can split a page in several ones, probably per driver directory.


Thiemo


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Goswin von Brederlow]

Sven Luther <[EMAIL PROTECTED]> writes:

> On Tue, Aug 08, 2006 at 08:12:48PM -0400, Jim Crilly wrote:
>> On 08/08/06 04:49:33PM -0700, Thomas Bushnell BSG wrote:
>> > Sven Luther <[EMAIL PROTECTED]> writes:
>> > 
>> > > Well, it reads to me that we won't screw our users without second
>> > > thought like some here are proposing.
>> > 
>> > In my opinion, we have been screwing our users for years by lying to
>> > them about whether their software was free.  We would even say things
>> > like "hardware such-and-such is supportable with free software" and
>> > then ship them a non-free driver.
>> > 
>> 
>> I'm sure this has been suggested/covered before, but what's wrong with just
>> sticking those drivers in non-free and giving the user a choice during
>
> Well, i mentioned this already elsewhere in this thread, but there you go :
>
>   1) it is lot of work, and we (the kernel team) don't realy have the 
> ressources
>   for it. 

Then stop doing 0 day uploads and fix the kernel. No matter how long
it takes. It is a release blocker, etch will wait for you.

If you need more help then ask for it (again). Debian-devel-anounce
would probably be a good idea.

>   2) there is currently no exhaustive list of affected drivers, there may even
>   be some case of things like main processor micro-code affected.

Fix what you know and keep the rest in blissfull ignorance.

>   3) it demands works of part of debian outside the kernel team, particularly
>   the d-i and eventually archive folk. The d-i have not been cooperative to
>   this idea, and even mentioning it to them has resulted in a barrage of
>   agresive bashing. But then maybe it was just because they don't like me and
>   i dared to mention this all those months back. In any case, they have not
>   fixed their side of it, and there appears to be no plan to do so, i was
>   kicked out of the d-i project, and Frans threatened me if i even dared work
>   on kernel/d-i based issues.

Sorry, that is just no reason to break the social contract and
dfsg. Yes you have to break D-I but they can fix it. They have been
told about it and are aware of it. Once it becomes virtualy required
they will fix it for sure. So far it isn't. As I said before, don't
wait for them to work ahead but force the issue on them. The gravity
of it requires it.

>> installation? Sure, it'll screw the users that won't have Internet access
>> during the installation, but as long as it's possible to make custom
>> installation discs that'll probably take care of itself.
>
> You can do a CD media which includes the non-free modules, you would have to
> build a non-free d-i image set anyway.

Which would be a task for the debian-cd team. Has anyone talk to them
about it?

> Friendly,
>
> Sven Luther

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Sven Luther]

On Thu, Aug 10, 2006 at 03:51:31PM +0200, Goswin von Brederlow wrote:
> Sven Luther <[EMAIL PROTECTED]> writes:
> >
> >   1) it is lot of work, and we (the kernel team) don't realy have the 
> > ressources
> >   for it. 
> 
> Then stop doing 0 day uploads and fix the kernel. No matter how long
> it takes. It is a release blocker, etch will wait for you.

Your patches are welcome.

> If you need more help then ask for it (again). Debian-devel-anounce
> would probably be a good idea.

Please go ahead and find people willing to work on this, you hardly need our
help for this.

> >   2) there is currently no exhaustive list of affected drivers, there may 
> > even
> >   be some case of things like main processor micro-code affected.
> 
> Fix what you know and keep the rest in blissfull ignorance.

As said, your patches would be wlecome.

> >   3) it demands works of part of debian outside the kernel team, 
> > particularly
> >   the d-i and eventually archive folk. The d-i have not been cooperative to
> >   this idea, and even mentioning it to them has resulted in a barrage of
> >   agresive bashing. But then maybe it was just because they don't like me 
> > and
> >   i dared to mention this all those months back. In any case, they have not
> >   fixed their side of it, and there appears to be no plan to do so, i was
> >   kicked out of the d-i project, and Frans threatened me if i even dared 
> > work
> >   on kernel/d-i based issues.
> 
> Sorry, that is just no reason to break the social contract and
> dfsg. Yes you have to break D-I but they can fix it. They have been

Err, given the way i was bashed the last time this happened, no, sorry, i will
not even dare try somethign such in the near future.

> told about it and are aware of it. Once it becomes virtualy required
> they will fix it for sure. So far it isn't. As I said before, don't
> wait for them to work ahead but force the issue on them. The gravity
> of it requires it.

Maybe, but the same could be said of you, you care for this, help us fix it,
and then there will be no other choice than follow your lead. As always,
patches welcome.

> >> installation? Sure, it'll screw the users that won't have Internet access
> >> during the installation, but as long as it's possible to make custom
> >> installation discs that'll probably take care of itself.
> >
> > You can do a CD media which includes the non-free modules, you would have to
> > build a non-free d-i image set anyway.
> 
> Which would be a task for the debian-cd team. Has anyone talk to them
> about it?

Currently there is no infrastructure to build non-free d-i images. doing
non-free cds would be rather easy, and it is something i can do myself, as i
still have svn access to the debian-cd project. 

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Goswin von Brederlow]

Sven Luther <[EMAIL PROTECTED]> writes:

> On Mon, Aug 07, 2006 at 02:48:08PM +0200, Goswin von Brederlow wrote:
>> Sven Luther <[EMAIL PROTECTED]> writes:
>> And even for an aggregation of works the DFSG holds and you are still
>> in trouble.
>
> Sure, the DFSG says that we need the source code for those, and they are thus
> non-free, but what i am arguing is that they are not violation of the kernel
> GPL, since they are separate aggregate works.

As part of the source files they are seperate works. When you compile
and LINK them all together they become one work. Just like when you
link in non GPL static (or even dynamic) libraries.

>> Let me make another example. I take a GPL program and link in a
>> non-free library plus glue code that forks a child and uses the
>> library. Only the child does use the non-free library and the
>> communication between father and child is clearly defined.
>
> Let me make another example. You buy a random bunch of hardware, and either
> run linux on it, or run a free linux driver running it. This hardware in
> question happens to have some random bios on it, which is non-free, or some
> fpga config file hidden in a flash.
>
> This is exactly the same case as the one you are describing, with the sole
> exception of the firmware in question being temporarily transported in the
> kernel binary and uploaded in the device.

No, to get the same case you have to read out the bios/flash and
include that in Debian to be distributed by debian in main. If you do
that the hardware vendor would sue you in a minute for copyright
infringement because you don't even have distribution rights.

> Finally, what you mention is more akin to the unicorn driver, which is a
> driver for a soft-ADSL pci modem, which links to a non-free, binary-only,
> x86-only ADSL library. This is indeed more than just agregation, and after i
> engaged bewan over it, and we consulted with RMS and the FSF, they released
> their drivers with a GPL+exception licence, and the package is now happily
> sitting in non-free, waiting for someone to write a free ADSL library
> replacement.

Indeed. That was one of the bad examples.

>> The non-free library never runs in the same address space as the rest
>> of the program. Does that mean this is just an aggregation of works
>> and GPL compliant?
>
> I am not familiar enough with how library are run, but there is some very
> different way in which libraries called by programs work, and the way the main
> cpu interacts with a peripheral processor on a pci card, don't you think ? Or
> do you want also to declare that you can run GPLed Linux kernels only on
> hardware whose VHDL of every chip on it as well as schematics and gerbers are
> freely available, not counting that you would also need free PCB design tools
> which can read the format, as well as free tools running the manufacturing
> plant, and so on ...

_IF_ Debian would distribute the CPU in main then zes, I would require
that. But Debian is not a hardware vendor.

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.

>> I've been bugging Bastian about this issue as well since I need this for
>> 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
writing a patch. You've done D-I work before so maybe you even looked
at libd-i source before.

> 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.

>> 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 care and I'm not afraid to suffer your treatment beca

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Goswin von Brederlow]

Sven Luther <[EMAIL PROTECTED]> writes:

> On Thu, Aug 10, 2006 at 03:51:31PM +0200, Goswin von Brederlow wrote:
>> Sven Luther <[EMAIL PROTECTED]> writes:
>> Which would be a task for the debian-cd team. Has anyone talk to them
>> about it?
>
> Currently there is no infrastructure to build non-free d-i images. doing
> non-free cds would be rather easy, and it is something i can do myself, as i
> still have svn access to the debian-cd project. 
>
> Friendly,
>
> Sven Luther

There we go. Something constructive for you to do that you are
intrested in anyway.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Sven Luther]

On Thu, Aug 10, 2006 at 04:32:52PM +0200, Goswin von Brederlow wrote:
> Sven Luther <[EMAIL PROTECTED]> writes:
> 
> > On Mon, Aug 07, 2006 at 02:48:08PM +0200, Goswin von Brederlow wrote:
> >> Sven Luther <[EMAIL PROTECTED]> writes:
> >> And even for an aggregation of works the DFSG holds and you are still
> >> in trouble.
> >
> > Sure, the DFSG says that we need the source code for those, and they are 
> > thus
> > non-free, but what i am arguing is that they are not violation of the kernel
> > GPL, since they are separate aggregate works.
> 
> As part of the source files they are seperate works. When you compile
> and LINK them all together they become one work. Just like when you
> link in non GPL static (or even dynamic) libraries.

Please read last years discussion on debian-legal where this was exposed in
detail, and a consensus was found which i reflect in my position here.

Think of the case of a windows compression program which produce binaries with
builtin uncompressor binaries.

What you claim is that using those (winzip and co) to compress the linux
kernel source would break the GPL, because they are physically housed in the
same binary.

> >> Let me make another example. I take a GPL program and link in a
> >> non-free library plus glue code that forks a child and uses the
> >> library. Only the child does use the non-free library and the
> >> communication between father and child is clearly defined.
> >
> > Let me make another example. You buy a random bunch of hardware, and either
> > run linux on it, or run a free linux driver running it. This hardware in
> > question happens to have some random bios on it, which is non-free, or some
> > fpga config file hidden in a flash.
> >
> > This is exactly the same case as the one you are describing, with the sole
> > exception of the firmware in question being temporarily transported in the
> > kernel binary and uploaded in the device.
> 
> No, to get the same case you have to read out the bios/flash and
> include that in Debian to be distributed by debian in main. If you do
> that the hardware vendor would sue you in a minute for copyright
> infringement because you don't even have distribution rights.

Notice that i am not arguing that the firmware is not non-free and doesn't
break the DSFG, but that the firmware is not a derived work of the linux
kernel, just aggregated on the same distribution media (the linux binary
file), i think you are seriously confusing the two in your above
argumentation. The first makes the firmware unfit to be in main, while the
second is a GPL violation of the kernel source, and forbids all distribution
of it.

> > Finally, what you mention is more akin to the unicorn driver, which is a
> > driver for a soft-ADSL pci modem, which links to a non-free, binary-only,
> > x86-only ADSL library. This is indeed more than just agregation, and after i
> > engaged bewan over it, and we consulted with RMS and the FSF, they released
> > their drivers with a GPL+exception licence, and the package is now happily
> > sitting in non-free, waiting for someone to write a free ADSL library
> > replacement.
> 
> Indeed. That was one of the bad examples.

Indeed. It is non-free, and the problematicness of the licencing has been
solved. It is an out-of-tree module though, so not something to worry about in
this case.

> >> The non-free library never runs in the same address space as the rest
> >> of the program. Does that mean this is just an aggregation of works
> >> and GPL compliant?
> >
> > I am not familiar enough with how library are run, but there is some very
> > different way in which libraries called by programs work, and the way the 
> > main
> > cpu interacts with a peripheral processor on a pci card, don't you think ? 
> > Or
> > do you want also to declare that you can run GPLed Linux kernels only on
> > hardware whose VHDL of every chip on it as well as schematics and gerbers 
> > are
> > freely available, not counting that you would also need free PCB design 
> > tools
> > which can read the format, as well as free tools running the manufacturing
> > plant, and so on ...
> 
> _IF_ Debian would distribute the CPU in main then zes, I would require
> that. But Debian is not a hardware vendor.

Ah, again you are confused. We are not discussing the DFSG-freeness, but the
violation of the GPL of the kernel here. Two totally separate matters, please
read the debian-legal argumentation of last year about this issue in order to
clarify your comprehension of this issue.

> 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.

> >> multiarch. I have a hacked together cdebootstrap that first
> >> concatenates the Packages files from mu

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Russ Allbery]

Nathanael Nerode <[EMAIL PROTECTED]> writes:

> The point of my initial message was not to argue: it was that the etch
> timeline is unrealistic, because I see no progress on removing the
> substantial number of sourceless binaries from the Linux kernel source
> package, and it's *after* the kernel was supposed to have frozen!

Please don't lose track of the fact that there's nothing inherently wrong
with a sourceless binary if that's all the source anyone *has*.  If the
assembly was painstakingly reverse-engineered, it *is* the source for all
intents and purposes, and no license requires that the author supply
something which doesn't actually exist.  This of course doesn't apply to
binary blobs given to us by people who generated them from some source
they're not releasing, of course.

I don't know how many of the files you're talking about may fall into this
category, but this distinction seems to be lost in this thread and I don't
want people to miss it.  It *does* happen that the concept of source isn't
overly meaningful for some things.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Sven Luther]

On Thu, Aug 10, 2006 at 04:50:29PM +0200, Goswin von Brederlow wrote:
> Sven Luther <[EMAIL PROTECTED]> writes:
> 
> > On Thu, Aug 10, 2006 at 03:51:31PM +0200, Goswin von Brederlow wrote:
> >> Sven Luther <[EMAIL PROTECTED]> writes:
> >> Which would be a task for the debian-cd team. Has anyone talk to them
> >> about it?
> >
> > Currently there is no infrastructure to build non-free d-i images. doing
> > non-free cds would be rather easy, and it is something i can do myself, as i
> > still have svn access to the debian-cd project. 
> >
> > Friendly,
> >
> > Sven Luther
> 
> There we go. Something constructive for you to do that you are
> intrested in anyway.

I am interested in lot of stuff, but the point we are trying to make, is that
the kernel team has not the ressources to handle this as it should, so we
either keep the status quo, or get some outside help.

Of all those complaining about the non-free modules, and asking why we have
not fixed it yet, almost nobody has come up and actually proposed help, just,
as you did, propose we somehow find more free time to work on it.

So, i have given a few hints on how even kernel team outsiders with no kernel
coding experience can start to give a hand on this. Nobody replied to that
call for help yet, the ball is in your camp.

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Goswin von Brederlow]

Sven Luther <[EMAIL PROTECTED]> writes:

> On Thu, Aug 10, 2006 at 04:32:52PM +0200, Goswin von Brederlow wrote:
>> Sven Luther <[EMAIL PROTECTED]> writes:
>> 
>> > I am not familiar enough with how library are run, but there is some very
>> > different way in which libraries called by programs work, and the way the 
>> > main
>> > cpu interacts with a peripheral processor on a pci card, don't you think ? 
>> > Or
>> > do you want also to declare that you can run GPLed Linux kernels only on
>> > hardware whose VHDL of every chip on it as well as schematics and gerbers 
>> > are
>> > freely available, not counting that you would also need free PCB design 
>> > tools
>> > which can read the format, as well as free tools running the manufacturing
>> > plant, and so on ...
>> 
>> _IF_ Debian would distribute the CPU in main then zes, I would require
>> that. But Debian is not a hardware vendor.
>
> Ah, again you are confused. We are not discussing the DFSG-freeness, but the
> violation of the GPL of the kernel here. Two totally separate matters, please
> read the debian-legal argumentation of last year about this issue in order to
> clarify your comprehension of this issue.

You misread me.

Debian is NOT distributing hardware. Therefore any license of software
included with the hardware is totaly irelevant to Debian.

If you want to buy only free hardware that is your problem and we are
all sorry that you won't be able to so. But it is not a problem with
the SC or DFSG that you can't. Hardware is also not included in any
GPL software including the linux kernel. Your "hardware is not free"
argument is totaly besides the issue. That is what I ment.

>> 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.

>> >> 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.

When you take the firmware out of the hardware and into debian / the
kernel then it can become an issue, not before.

>> 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)

>> >> 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 curren

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Sven Luther]

On Thu, Aug 10, 2006 at 06:14:08PM +0200, Goswin von Brederlow wrote:
> Sven Luther <[EMAIL PROTECTED]> 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.

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Thomas Bushnell BSG]

Russ Allbery <[EMAIL PROTECTED]> writes:

> Please don't lose track of the fact that there's nothing inherently wrong
> with a sourceless binary if that's all the source anyone *has*.  

I think in most of the cases under consideration, we have firmware
which a hardware manufacturer wrote and then either published or stuck
inside a windows driver, and which then found its way into a Linux
driver.

So while your statement is right, the relevant "anyone" includes the
hardware manufacturer, who quite likely does have source in a more
convenient form than a pure binary.

> If the
> assembly was painstakingly reverse-engineered, it *is* the source for all
> intents and purposes [...]

Quite right, but assembly code is *not* binary.

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Goswin von Brederlow]

Sven Luther <[EMAIL PROTECTED]> writes:

> On Thu, Aug 10, 2006 at 06:14:08PM +0200, Goswin von Brederlow wrote:
>> Sven Luther <[EMAIL PROTECTED]> 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.

And actualy just recently the first one was uploaded to non-free
including udebs:

http://ftp.debian.org/debian/pool/non-free/f/firmware-non-free/

Now the DAK must be configured to create a
dists/sid/non-free/debian-installer/ subdir and index files for the
udebs. But I feel we are already one step closer to the goal.

Step 1: Create non-free udebs.  *checked*
Step 2: Add DAK config  *waiting for ftp-masters*
Step 3: Add D-I support

>> 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.
>
> Friendly,
>
> Sven Luther

Luckily Debian is about free software so you can do that. But please
just do and not repeat the story and fork thread over and over. Even I
get sick of it and I liked you when we happened to meet in person.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Sven Luther]

On Sat, Aug 12, 2006 at 12:46:18AM +0200, Goswin von Brederlow wrote:
> Sven Luther <[EMAIL PROTECTED]> writes:
> 
> > On Thu, Aug 10, 2006 at 06:14:08PM +0200, Goswin von Brederlow wrote:
> >> Sven Luther <[EMAIL PROTECTED]> 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.
> 
> And actualy just recently the first one was uploaded to non-free
> including udebs:
> 
> http://ftp.debian.org/debian/pool/non-free/f/firmware-non-free/
> 
> Now the DAK must be configured to create a
> dists/sid/non-free/debian-installer/ subdir and index files for the
> udebs. But I feel we are already one step closer to the goal.
> 
> Step 1: Create non-free udebs.  *checked*
> Step 2: Add DAK config  *waiting for ftp-masters*
> Step 3: Add D-I support

I would propose something even more advanced, and not put the kernel .udebs
into the main debian-installer thing, but into a separate section.

The way i envision this, we would create a debian/sid/main|non-free/kernel
section, where the kernel .udebs would be hold, and we start building them
from the main kernel package.

Ideally, we would go a step further, and have
debian/sid/main|non-free/kernel/ sections, so we can split the kernel
.udeb packages in a finer grain, and each running installer will only be
seeing the modules corresponding to the kernel flavour he is running.

This was my proposal from the start, and if you think down to it, it is the
best solution for all the kernel/d-i related problems, and would allow to
complete the work started with the common packaging, into a solution where
there will be only a single package build, easily doable on the usual buildd
network, will allow the most flexible solution for abi bumps and security
upgrades.

But then, i was not able to complete these ideas, due to my mothers illness
and death, and the inexcusable behaviour of the d-i folk, frans at the
foremost of them. They prefer to keep the status quo, and do lot of work, and
complain about abi changes, as well as being able to blame the "lazy porters"
(direct quotation of joey hess) for any problem. This is the thing which led
me in clash with them. They perfectly knew about various d-i brokeness in the
buildd, chose not to say anything to the porters, and because i was not attent
enough to the issue to notice immediately, because i was at my mothers
ill-bed, they chose to bash me and subsequently kick me out.

This is the worse behaviour that i have seen from any DD so far, even jonathan
and even Andrew had more decent behaviour than this, and the worse of this is
that none of the others involved, not evben the DPL, have found anything wrong
with this behaviour, or at least dared to say something about it, in fear to
that frans would be pissed and leave, and they would miss the work he has been
doing on d-i. 

So, you see, if i am angry and hurt, and you dislike me repeating it always,
you know who to blame. 

> >> 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.
> >
> > Friendly,
> >
> > Sven Luther
> 
> Luckily Debian is about free software so you can do that. But please
> just do and not repeat the story and fork thread over and over. Even I
> get sick of it and I liked you when we happened to meet in person.

Yeah, but notice that if the d-i team had not chosen to kick me out while i
was hurt and crying for the death of my mother, none of this would be
happening, and we would all code happily thereafter. I asked the DPL to
mediate this, but the only conclusion was that i should fork, which is not
satisfactory. It has been going on since april, and the more i came to think
of it, the more i feel that their behaviour (Frans, joeyh, but also those
others who approved or at least didn't contradict them), was the worse that
any DD ever did, even worse thanb Andrew asking we don't offer our
condoleances to Jens wife, and that was already very grob.

So, if you like to be around with people with 

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Jonas Smedegaard]

On Sat, 12 Aug 2006 08:40:44 +0200 Sven Luther wrote:

> So, if you like to be around with people with total lack of human
> decency, then you should accept when they are criticized for it.

And/or you should stop repeating yourself.

-- 
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

 - Enden er nær: http://www.shibumi.org/eoti.htm


pgpPd3wkOTVKE.pgp
Description: PGP signature

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Goswin von Brederlow]

CC limited to debian-kernel as this isn't for release anymore.

Sven Luther <[EMAIL PROTECTED]> writes:

> On Sat, Aug 12, 2006 at 12:46:18AM +0200, Goswin von Brederlow wrote:
>> And actualy just recently the first one was uploaded to non-free
>> including udebs:
>> 
>> http://ftp.debian.org/debian/pool/non-free/f/firmware-non-free/
>> 
>> Now the DAK must be configured to create a
>> dists/sid/non-free/debian-installer/ subdir and index files for the
>> udebs. But I feel we are already one step closer to the goal.
>> 
>> Step 1: Create non-free udebs.  *checked*
>> Step 2: Add DAK config  *waiting for ftp-masters*
>> Step 3: Add D-I support
>
> I would propose something even more advanced, and not put the kernel .udebs
> into the main debian-installer thing, but into a separate section.
>
> The way i envision this, we would create a debian/sid/main|non-free/kernel
> section, where the kernel .udebs would be hold, and we start building them
> from the main kernel package.
>
> Ideally, we would go a step further, and have
> debian/sid/main|non-free/kernel/ sections, so we can split the kernel
> .udeb packages in a finer grain, and each running installer will only be
> seeing the modules corresponding to the kernel flavour he is running.

What for? The installer always needs the installer udebs. Having the
kernel udebs in another section just means more files to generate and
to download that can go wrong. It saves nothing.

Splitting the udebs by flavour would save a few bytes on the Packages
file but the only affect that has would be a few bytes less downloaded
(inconsequential) and a few bytes less ram used (if you are that low
then you have problems anyway).

If you want the user to only see the kernel components that match the
running kernel then filter them in the display. I don't think
splintering the Index files into tons of sections is the way to go
there. Also think about what that would mean for a newly added kernel
flavour in terms of delays till the DAK gets reconfigured for a new
section.

> This was my proposal from the start, and if you think down to it, it is the
> best solution for all the kernel/d-i related problems, and would allow to
> complete the work started with the common packaging, into a solution where
> there will be only a single package build, easily doable on the usual buildd
> network, will allow the most flexible solution for abi bumps and security
> upgrades.

The layout of the Index files and sections used has absoluetly no
effect on either abi bumps nor security nor in any way the package
building. Extra sections just means much more work for the DAK with
little to no benefit. I don't even consider that a good
solution. Quite opposite. The requirement of a new section for a new
kernel flavour would create a lot of delays for the kernel-team when
adding a new flavour.

> But then, i was not able to complete these ideas, due to my mothers illness
...

And there you go again. STOP IT PLEASE. It is totaly off-topic.

...
> So, you see, if i am angry and hurt, and you dislike me repeating it always,
> you know who to blame. 

You for repeating it over and over. With every repetition the
precieved blames shifts a little bit to your side until all people see
precieve is that you are to blame.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Sven Luther]

On Sat, Aug 12, 2006 at 03:13:13PM +0200, Goswin von Brederlow wrote:
> CC limited to debian-kernel as this isn't for release anymore.
> 
> Sven Luther <[EMAIL PROTECTED]> writes:
> 
> > On Sat, Aug 12, 2006 at 12:46:18AM +0200, Goswin von Brederlow wrote:
> >> And actualy just recently the first one was uploaded to non-free
> >> including udebs:
> >> 
> >> http://ftp.debian.org/debian/pool/non-free/f/firmware-non-free/
> >> 
> >> Now the DAK must be configured to create a
> >> dists/sid/non-free/debian-installer/ subdir and index files for the
> >> udebs. But I feel we are already one step closer to the goal.
> >> 
> >> Step 1: Create non-free udebs.  *checked*
> >> Step 2: Add DAK config  *waiting for ftp-masters*
> >> Step 3: Add D-I support
> >
> > I would propose something even more advanced, and not put the kernel .udebs
> > into the main debian-installer thing, but into a separate section.
> >
> > The way i envision this, we would create a debian/sid/main|non-free/kernel
> > section, where the kernel .udebs would be hold, and we start building them
> > from the main kernel package.
> >
> > Ideally, we would go a step further, and have
> > debian/sid/main|non-free/kernel/ sections, so we can split the 
> > kernel
> > .udeb packages in a finer grain, and each running installer will only be
> > seeing the modules corresponding to the kernel flavour he is running.
> 
> What for? The installer always needs the installer udebs. Having the
> kernel udebs in another section just means more files to generate and
> to download that can go wrong. It saves nothing.

The installer needs the installer .udebs of the flavours it is using, but
hardly any others. This mean we would save on memory space used to hold the 3
in-memory copy of the Packages file.

> Splitting the udebs by flavour would save a few bytes on the Packages
> file but the only affect that has would be a few bytes less downloaded
> (inconsequential) and a few bytes less ram used (if you are that low
> then you have problems anyway).

But it would make space for a more fine-grained .udeb classification, which
would in turn result in a considerable memory and bandwidth saving, as only
the modules really used are downloaded.

Furthermore this will allow the kernel .udebs to be moved into the common
kernel package, without costing the installer folk any flexibility, as they
will not have need to balance the module .udebs and thus keep control of them.

Furthermore, with a set of smart tools, some Makefile/Kconfig analysis, and a
bit of graph theory, it would allow to automate the module .udeb creation,
based only on the choice of .config options, and thus make the job of the
porters so much easier, needing only to consider the config options one single
time, to see if they need to be enabled, and then decide if this particular
option is one which would enable a module which would be needed for the
installer.

All the rest, the description, the depednecy graph, etc, will be taken from
the kernel source directly (with a few overrides for dependencies for some
modules who do not (yet maybe) carry the dependency information in their
source code.

> If you want the user to only see the kernel components that match the
> running kernel then filter them in the display. I don't think

Well, apart from the installer pulling some 2.4.27-apus .udebs in on a
2.6.12-powerpc flavour, which is indeed a mistake which would be solved by
this solution, this is hardly the point.

The main point here, is that it is easily doable to automate a set of tasks,
and to keep only the small minimum set of human decision in a single place,
and thus spare everyone a lot of work, which is after all what computers where
invented for in the first place.

Compare this to the current situation, favored by the installer team, probably
just to oppose me, where every porter has to redo the module selection job by
hand, where none of them are informed about the problems faced by the others,
where a slight indisponibility of one of the porters result in thee brokeness
of the related build, and accusations of lazyness by the d-i leaders, and you
see how this would be dissatisfying, and how the d-i leaders in their
pettiness see my technical proposals as an attack against their supremacy.

> splintering the Index files into tons of sections is the way to go
> there. Also think about what that would mean for a newly added kernel
> flavour in terms of delays till the DAK gets reconfigured for a new
> section.

Indeed. But then, there is probably another set of modifications that could be
done to help this go around. The kernel team has already stated that they are
not really happy in the way of how NEW is handled in relation of kernels.

Another solution to the non-free DFSG mess and this would be to take the
kernel fully out of debian, and have our own infrastructure to handle it as we
see fit. This would solve the problem of those people in debian who like to do
unneeded work, and im

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Goswin von Brederlow]

Sven Luther <[EMAIL PROTECTED]> writes:

>> What for? The installer always needs the installer udebs. Having the
>> kernel udebs in another section just means more files to generate and
>> to download that can go wrong. It saves nothing.
>
> The installer needs the installer .udebs of the flavours it is using, but
> hardly any others. This mean we would save on memory space used to hold the 3
> in-memory copy of the Packages file.

-rw-r--r-- 1 reprepro nogroup 187K Aug 11 04:53 
dists/sid/main/debian-installer/binary-amd64/Packages

Is that really a problem? If so then work on reducing the number of
copies from 3 to 1 plus a compressed one. You could also filter out
kernel modules for other flavours while downloading the file prior top
saving it. For more space filter out all the udebs already installed too.

Having all the udebs in one Packages file is convenient for
debian-installer when building, for debian-cd, for mirror scripts and
so on. Don't forget that.

And don't forget that the businesscard or netinst CDs have filtered
Packages files for the udebs with only the right udebs in there. Only
the netboot and full CD images waste those few Kb.

>> Splitting the udebs by flavour would save a few bytes on the Packages
>> file but the only affect that has would be a few bytes less downloaded
>> (inconsequential) and a few bytes less ram used (if you are that low
>> then you have problems anyway).
>
> But it would make space for a more fine-grained .udeb classification, which
> would in turn result in a considerable memory and bandwidth saving, as only
> the modules really used are downloaded.
>
> Furthermore this will allow the kernel .udebs to be moved into the common
> kernel package, without costing the installer folk any flexibility, as they
> will not have need to balance the module .udebs and thus keep control of them.

More udebs increases the Packages files. That works contrary to what
you want (save space). As for saving download bandwith, saving 1MB of
udebs compared to the 500-2000MB debs of a normal install is quite
incosequential. You might be optimizing at the wrong end here.

I also see how more sections would change any of this? Has someone
said we can't do finer grained kernel module udebs because the
Packages file will grow to big with all those udebs? I think a far
bigger reason would be flooding NEW with so many tiny udebs on an ABI
change and thus driving ftp-master nuts.

> Furthermore, with a set of smart tools, some Makefile/Kconfig analysis, and a
> bit of graph theory, it would allow to automate the module .udeb creation,
> based only on the choice of .config options, and thus make the job of the
> porters so much easier, needing only to consider the config options one single
> time, to see if they need to be enabled, and then decide if this particular
> option is one which would enable a module which would be needed for the
> installer.
>
> All the rest, the description, the depednecy graph, etc, will be taken from
> the kernel source directly (with a few overrides for dependencies for some
> modules who do not (yet maybe) carry the dependency information in their
> source code.

You can already do that. Just because the modules are not copied into
udebs at the end does not mean you can't pretend. Just imagine they
get copied and do all your magic. After that you have a set of modules
and the depmod file for them that D-I uses to split modules into
udebs.

>> If you want the user to only see the kernel components that match the
>> running kernel then filter them in the display. I don't think
>
> Well, apart from the installer pulling some 2.4.27-apus .udebs in on a
> 2.6.12-powerpc flavour, which is indeed a mistake which would be solved by
> this solution, this is hardly the point.
>
> The main point here, is that it is easily doable to automate a set of tasks,
> and to keep only the small minimum set of human decision in a single place,
> and thus spare everyone a lot of work, which is after all what computers where
> invented for in the first place.

No automation exists so for now someone has to do it manualy and that
someone is the D-I team currently as they know what D-I needs. And not
the kernel-team. Currently building udebs from the linux-2.6 source
would add another indirection to the build process, not remove one.

> Compare this to the current situation, favored by the installer team, probably
> just to oppose me, where every porter has to redo the module selection job by
> hand, where none of them are informed about the problems faced by the others,
> where a slight indisponibility of one of the porters result in thee brokeness
> of the related build, and accusations of lazyness by the d-i leaders, and you
> see how this would be dissatisfying, and how the d-i leaders in their
> pettiness see my technical proposals as an attack against their supremacy.

The same can be said to happen for the kernel-team. Changing
responcibility to another team does not magicaly so

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Sven Luther]

On Sat, Aug 12, 2006 at 07:46:16PM +0200, Goswin von Brederlow wrote:
> Sven Luther <[EMAIL PROTECTED]> writes:
> 
> >> What for? The installer always needs the installer udebs. Having the
> >> kernel udebs in another section just means more files to generate and
> >> to download that can go wrong. It saves nothing.
> >
> > The installer needs the installer .udebs of the flavours it is using, but
> > hardly any others. This mean we would save on memory space used to hold the 
> > 3
> > in-memory copy of the Packages file.
> 
> -rw-r--r-- 1 reprepro nogroup 187K Aug 11 04:53 
> dists/sid/main/debian-installer/binary-amd64/Packages
> 
> Is that really a problem? If so then work on reducing the number of
> copies from 3 to 1 plus a compressed one. You could also filter out
> kernel modules for other flavours while downloading the file prior top
> saving it. For more space filter out all the udebs already installed too.
> 
> Having all the udebs in one Packages file is convenient for
> debian-installer when building, for debian-cd, for mirror scripts and
> so on. Don't forget that.
> 
> And don't forget that the businesscard or netinst CDs have filtered
> Packages files for the udebs with only the right udebs in there. Only
> the netboot and full CD images waste those few Kb.
> 
> >> Splitting the udebs by flavour would save a few bytes on the Packages
> >> file but the only affect that has would be a few bytes less downloaded
> >> (inconsequential) and a few bytes less ram used (if you are that low
> >> then you have problems anyway).
> >
> > But it would make space for a more fine-grained .udeb classification, which
> > would in turn result in a considerable memory and bandwidth saving, as only
> > the modules really used are downloaded.
> >
> > Furthermore this will allow the kernel .udebs to be moved into the common
> > kernel package, without costing the installer folk any flexibility, as they
> > will not have need to balance the module .udebs and thus keep control of 
> > them.
> 
> More udebs increases the Packages files. That works contrary to what

Indeed. The proposal to split the packages file in a per flavour kernel
repository comes directly from the need to counterbalance this augmentation of
the number of packages.

Also, do you really need a gazillion of not-for-your-hardware modules
installed ? 

> you want (save space). As for saving download bandwith, saving 1MB of
> udebs compared to the 500-2000MB debs of a normal install is quite
> incosequential. You might be optimizing at the wrong end here.

Indeed.

> I also see how more sections would change any of this? Has someone
> said we can't do finer grained kernel module udebs because the
> Packages file will grow to big with all those udebs? I think a far

Indeed, this was the main critic against the finer grained module proposal
(apart from all the hateful stuff they said to me at the same time naturally).

> bigger reason would be flooding NEW with so many tiny udebs on an ABI
> change and thus driving ftp-master nuts.

Nope, because they would all be part of the same source package, and i think
they can easily enough authorize all binaries of a single source package.

> 
> > Furthermore, with a set of smart tools, some Makefile/Kconfig analysis, and 
> > a
> > bit of graph theory, it would allow to automate the module .udeb creation,
> > based only on the choice of .config options, and thus make the job of the
> > porters so much easier, needing only to consider the config options one 
> > single
> > time, to see if they need to be enabled, and then decide if this particular
> > option is one which would enable a module which would be needed for the
> > installer.
> >
> > All the rest, the description, the depednecy graph, etc, will be taken from
> > the kernel source directly (with a few overrides for dependencies for some
> > modules who do not (yet maybe) carry the dependency information in their
> > source code.
> 
> You can already do that. Just because the modules are not copied into
> udebs at the end does not mean you can't pretend. Just imagine they
> get copied and do all your magic. After that you have a set of modules
> and the depmod file for them that D-I uses to split modules into
> udebs.

"the depmod file that D-I uses to split modules into .udebs". You must be
living in another planet than me. Right now the modules are split manually, in
a stupid painstakingly repetitive and time-consuming way. And you can't even
per-arch/subarch override properly the default choice done in kernel-wedge.

Notice also that the apus flavour was killed from d-i once they kicked me out,
because it was too much work for them to fix it.

> >> If you want the user to only see the kernel components that match the
> >> running kernel then filter them in the display. I don't think
> >
> > Well, apart from the installer pulling some 2.4.27-apus .udebs in on a
> > 2.6.12-powerpc flavour, which is indeed a mistake which would be solved by
> > this so

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Goswin von Brederlow]

Sven Luther <[EMAIL PROTECTED]> writes:

> On Sat, Aug 12, 2006 at 07:46:16PM +0200, Goswin von Brederlow wrote:
>> Sven Luther <[EMAIL PROTECTED]> writes:
>> 
>> >> What for? The installer always needs the installer udebs. Having the
>> >> kernel udebs in another section just means more files to generate and
>> >> to download that can go wrong. It saves nothing.
>> >
>> > The installer needs the installer .udebs of the flavours it is using, but
>> > hardly any others. This mean we would save on memory space used to hold 
>> > the 3
>> > in-memory copy of the Packages file.
>> 
>> -rw-r--r-- 1 reprepro nogroup 187K Aug 11 04:53 
>> dists/sid/main/debian-installer/binary-amd64/Packages
>> 
>> Is that really a problem? If so then work on reducing the number of
>> copies from 3 to 1 plus a compressed one. You could also filter out
>> kernel modules for other flavours while downloading the file prior top
>> saving it. For more space filter out all the udebs already installed too.
>> 
>> Having all the udebs in one Packages file is convenient for
>> debian-installer when building, for debian-cd, for mirror scripts and
>> so on. Don't forget that.
>> 
>> And don't forget that the businesscard or netinst CDs have filtered
>> Packages files for the udebs with only the right udebs in there. Only
>> the netboot and full CD images waste those few Kb.
>> 
>> >> Splitting the udebs by flavour would save a few bytes on the Packages
>> >> file but the only affect that has would be a few bytes less downloaded
>> >> (inconsequential) and a few bytes less ram used (if you are that low
>> >> then you have problems anyway).
>> >
>> > But it would make space for a more fine-grained .udeb classification, which
>> > would in turn result in a considerable memory and bandwidth saving, as only
>> > the modules really used are downloaded.
>> >
>> > Furthermore this will allow the kernel .udebs to be moved into the common
>> > kernel package, without costing the installer folk any flexibility, as they
>> > will not have need to balance the module .udebs and thus keep control of 
>> > them.
>> 
>> More udebs increases the Packages files. That works contrary to what
>
> Indeed. The proposal to split the packages file in a per flavour kernel
> repository comes directly from the need to counterbalance this augmentation of
> the number of packages.

So instead of having 5 module udebs for my ONE generic kernel I get
200? For say amd64 it would be a big step back.

How many archs with flavours are we talking about anyway? I think m68k
has 3 flavours and ppc some and every other archs has a generic
flavour or drivers buildin already.

> Also, do you really need a gazillion of not-for-your-hardware modules
> installed ? 

All my hardware (that includes m68k) has absolutley 0 problems with
that. They will be installed in D-I and they will be installed on the
finished system. No point breaking my neck to get less installed
during D-I.

>> you want (save space). As for saving download bandwith, saving 1MB of
>> udebs compared to the 500-2000MB debs of a normal install is quite
>> incosequential. You might be optimizing at the wrong end here.
>
> Indeed.

So why then do you want to split module udebs?

You just agreed that downloading the module udebs is inconsequential
given their size. You agreed that more udebs increases the Index files
which is bad.

So all I'm left with is that you don't end up with as much modules in
the ramdisk. Something I find irelevant unless you talk about the
low-mem flavour.

Is the space taken up by the installed modules your actual argument
for having finer grained module udebs?

...
>> You can already do that. Just because the modules are not copied into
>> udebs at the end does not mean you can't pretend. Just imagine they
>> get copied and do all your magic. After that you have a set of modules
>> and the depmod file for them that D-I uses to split modules into
>> udebs.
>
> "the depmod file that D-I uses to split modules into .udebs". You must be
> living in another planet than me. Right now the modules are split manually, in
> a stupid painstakingly repetitive and time-consuming way. And you can't even
> per-arch/subarch override properly the default choice done in kernel-wedge.

Last I used it, and that is some time ago, the dependencies where
automatically checked on build. Maybe someone broke that but that
could be repaired easily enough.

...
>> the kernel-team. Currently building udebs from the linux-2.6 source
>> would add another indirection to the build process, not remove one.
>
> Another indirection ? It would mean that in a single upload, all kernel
> related .debs and .udebs are built. Furthermore, it allows to autobuild the
> kernel, which is not currently possible for the .udebs, which means 10+ times
> human intervention, uncoordinated uploads, uncoordinated NEW handling, random
> delays for each arch, and that the porters are left alone with random breakage
> introduced by untested changes of 

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Goswin von Brederlow]

[EMAIL PROTECTED] (Marco d'Itri) writes:

> On Aug 07, Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
>
>> > No, because those are not linked together with the GPLed code, but are a 
>> > mere
>> > aggregation of works inside the same media, i.e. the binary file. Those
>> > non-free firmware will never run inside the same memory space as the 
>> > kernel,
>> > and are offloaded to a peripheral processor, and the communication media
>> > between the kernel and this peripheral processor running said firmware is
>> > clearly defined, there is no doubt that those non-free firmware do not 
>> > break
>> > the kernel GPL.
>
>> They are linked in, they have symbols, the code directly references
>> their address. Can you name one tool that will easily remove such
> No. They are a char array, it's data copied where the hardware wants it.
> It's not code called by other functions.

That still leaves the symbol for the variable holding the char array
and its size. The code copying the data references that variable and
size. I didn't say the code is called.

Compare it to including a hexdump of an image or sound in a header
file and including that in the binary. And compare it with having that
same image or sound as external file shipped in the same deb.

Assume the image/sound was rendered/generated from some source format
not included in the source. E.g. povray input.

Is it an aggregation with the image linked into the binary?

>> "aggregated" code from the kernel image?
> Not relevant.

If it is an aggregation then there must be a way to break it up and
only keep the GPLed parts. I think that is very much relevant. I don't
think you can call something an aggregation if it is inseperably bound
together.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Sven Luther]

On Sat, Aug 12, 2006 at 10:32:54PM +0200, Goswin von Brederlow wrote:
> > Indeed. The proposal to split the packages file in a per flavour kernel
> > repository comes directly from the need to counterbalance this augmentation 
> > of
> > the number of packages.
> 
> So instead of having 5 module udebs for my ONE generic kernel I get
> 200? For say amd64 it would be a big step back.

Indeed, but smaller ones.

> How many archs with flavours are we talking about anyway? I think m68k
> has 3 flavours and ppc some and every other archs has a generic
> flavour or drivers buildin already.

I know that the more exotic ones have many flavours. Also, the amount of
packages will be proportional of the non-builtin drivers. POwerpc has
currently 5 d-i flavours (or would have if the new d-i powerpc people did they
work correctly), powerpc, powerpc64, powerpc-miboot, prep and apus. 

> > Also, do you really need a gazillion of not-for-your-hardware modules
> > installed ? 
> 
> All my hardware (that includes m68k) has absolutley 0 problems with
> that. They will be installed in D-I and they will be installed on the
> finished system. No point breaking my neck to get less installed
> during D-I.
> 
> >> you want (save space). As for saving download bandwith, saving 1MB of
> >> udebs compared to the 500-2000MB debs of a normal install is quite
> >> incosequential. You might be optimizing at the wrong end here.
> >
> > Indeed.
> 
> So why then do you want to split module udebs?

Because the current way of doing it is problematic. The d-i folk don't want to
give control of it to the kernel team, and the new proposal handled they
keeping the same and even better control of how to build the ramdisks, while
at the same time building the module .udebs from the common kernel source,
thus saving around 2 weeks of time the d-i folk need to adjust to a new abi or
version, thus making for more timely kernel security updates, and making the
work of the divers security teams easier.

> You just agreed that downloading the module udebs is inconsequential
> given their size. You agreed that more udebs increases the Index files
> which is bad.

Err, let's say we have 5 flavours like on powerpc, and each would have 200+
little module .udebs, which gives us Package numbers of 1000+. Worse if there
are more flavours. This is the part that joeyh objected to this plan of
spliting modules because of the fact that d-i loads three in memory copy of
the Packages file, which in turn prompted the idea of per-flavour
repositories.

If you look at the whole idea though, you find out that it is a really neat
solution to this problem, it cares for all the technical hurdles, and is
elegant and nice, and if you throw in the part that can be automated, it saves
work for everyone involved.

In my book, this makes it a good idea, or at least something that should be
tried, and not something you have to menace the implementator so he doesn't
dare pursue it.

> So all I'm left with is that you don't end up with as much modules in
> the ramdisk. Something I find irelevant unless you talk about the
> low-mem flavour.

And the fact that it is much easier to update config option and add and remove
new modules doesn't count. Naturally, you don't handle kernel .udebs. I did,
and it was a royal pain in the ass to handle those, it took me hours, for
stuff that was already done 10 times for the other flavours. And even a few
days ago, the powerpc64 flavour was still broken with the 2.6.17 kernels,
because some random module listed in the list of modules was not present.

The whole concept is of an extreme fragility, prone to break again and again,
cause lot of work for all involved, who become irritable, and bash on you when
you even mention it.

This, in my book, is not an example of good software engineering, and any
proposal to help improve this should be worth considering.

> Is the space taken up by the installed modules your actual argument
> for having finer grained module udebs?

Nope, but then i told you that in the first mail already :)

> ...
> >> You can already do that. Just because the modules are not copied into
> >> udebs at the end does not mean you can't pretend. Just imagine they
> >> get copied and do all your magic. After that you have a set of modules
> >> and the depmod file for them that D-I uses to split modules into
> >> udebs.
> >
> > "the depmod file that D-I uses to split modules into .udebs". You must be
> > living in another planet than me. Right now the modules are split manually, 
> > in
> > a stupid painstakingly repetitive and time-consuming way. And you can't even
> > per-arch/subarch override properly the default choice done in kernel-wedge.
> 
> Last I used it, and that is some time ago, the dependencies where
> automatically checked on build. Maybe someone broke that but that
> could be repaired easily enough.

The dependencies, yes, with a manual override which you have to use in
mysterious cases. The actual module list is fully

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Sven Luther]

On Sat, Aug 12, 2006 at 11:03:29PM +0200, Goswin von Brederlow wrote:
> [EMAIL PROTECTED] (Marco d'Itri) writes:
> 
> > On Aug 07, Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
> >
> >> > No, because those are not linked together with the GPLed code, but are a 
> >> > mere
> >> > aggregation of works inside the same media, i.e. the binary file. Those
> >> > non-free firmware will never run inside the same memory space as the 
> >> > kernel,
> >> > and are offloaded to a peripheral processor, and the communication media
> >> > between the kernel and this peripheral processor running said firmware is
> >> > clearly defined, there is no doubt that those non-free firmware do not 
> >> > break
> >> > the kernel GPL.
> >
> >> They are linked in, they have symbols, the code directly references
> >> their address. Can you name one tool that will easily remove such
> > No. They are a char array, it's data copied where the hardware wants it.
> > It's not code called by other functions.
> 
> That still leaves the symbol for the variable holding the char array
> and its size. The code copying the data references that variable and
> size. I didn't say the code is called.

Yeah, thanks very much. I suggest you go over to the FSF site, and read the
GPL faq, and then come back and discuss this again. I did so during that
discussion last year, and as said, that argumentation convinced the broadcom
legal department, and even the FSF had nothing to say against it.

A quick clue to help your search, the important parts are the one about the
'significant interface' or something such, and i seriously doubt that having a
single variable referencing the non-free stuff is enough for that.

Or else, consider this in a different way. On your computer disk, you have a
bunch of binary files, those are called partitions, and hold data in a
filesystem format. If you have any part of a GPLed binary on that filesystem,
which is referenced by an inode or similar, and a non-free work (and you have
probably bunch of unlicenced non-free stuff, like this email for example),
referenced by another inode, then this doesn't make this email a derivative
work of the linux kernel.

> Compare it to including a hexdump of an image or sound in a header
> file and including that in the binary. And compare it with having that
> same image or sound as external file shipped in the same deb.

Well, the FSF argues that it is not important where the file is, as long as
there is a logical link, in order to have the GPL cross the dynamic linking
barrier. In the same way, the only relationship of the non-free firmware or
your image or sound, is that it is transported in the same binary, and used as
data offloaded to the peripheral device.

> Assume the image/sound was rendered/generated from some source format
> not included in the source. E.g. povray input.

So ? What has this to do with it ? 

> Is it an aggregation with the image linked into the binary?

It depends if your binary is an image compressor, and only transports the
image, or if said image is used in the binary for icons of its GUI for example
or as splash screen.

> >> "aggregated" code from the kernel image?
> > Not relevant.
> 
> If it is an aggregation then there must be a way to break it up and
> only keep the GPLed parts. I think that is very much relevant. I don't
> think you can call something an aggregation if it is inseperably bound
> together.

Well, sure there is part to separate them. You could imagine a (non-free) tool
called before lilo or grub, and which would upload those firmwares for the
peripheral device to be ready when the free driver comes into play.

Or you could use the new initramfs/firmware loading kernel infrastructure to
separate the firmware from the kernel.

Err, is not this latest one what you are suggesting we do ? So, if i
understood you well, your own argumentation is hitting you back there, and
this is usually proof that there is something terribly wrong in your
argumentation to start with.

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Goswin von Brederlow]

Sven Luther <[EMAIL PROTECTED]> writes:

> On Sat, Aug 12, 2006 at 10:32:54PM +0200, Goswin von Brederlow wrote:
>> > Indeed. The proposal to split the packages file in a per flavour kernel
>> > repository comes directly from the need to counterbalance this 
>> > augmentation of
>> > the number of packages.
>> 
>> So instead of having 5 module udebs for my ONE generic kernel I get
>> 200? For say amd64 it would be a big step back.
>
> Indeed, but smaller ones.
>
>> How many archs with flavours are we talking about anyway? I think m68k
>> has 3 flavours and ppc some and every other archs has a generic
>> flavour or drivers buildin already.
>
> I know that the more exotic ones have many flavours. Also, the amount of
> packages will be proportional of the non-builtin drivers. POwerpc has
> currently 5 d-i flavours (or would have if the new d-i powerpc people did they
> work correctly), powerpc, powerpc64, powerpc-miboot, prep and apus. 

So the worst case is 5 flavours while most archs have only one. Your
solution would cut the number of kernel udebs by at most a factor of 5
while you want to increase by a factor of 40. That is still a net loss
by a factor of 8 for 5 flavours.

>> So why then do you want to split module udebs?
>
> Because the current way of doing it is problematic. The d-i folk don't want to
> give control of it to the kernel team, and the new proposal handled they
> keeping the same and even better control of how to build the ramdisks, while
> at the same time building the module .udebs from the common kernel source,
> thus saving around 2 weeks of time the d-i folk need to adjust to a new abi or
> version, thus making for more timely kernel security updates, and making the
> work of the divers security teams easier.

Who controls the udebs has nothing to do with splitting the module
udebs into smaller chunks. You could split them while D-I has control
of them or have them build by the kernel team and not split them up
further or do both. The two issues are independent of each other.

>> You just agreed that downloading the module udebs is inconsequential
>> given their size. You agreed that more udebs increases the Index files
>> which is bad.
>
> Err, let's say we have 5 flavours like on powerpc, and each would have 200+
> little module .udebs, which gives us Package numbers of 1000+. Worse if there
> are more flavours. This is the part that joeyh objected to this plan of
> spliting modules because of the fact that d-i loads three in memory copy of
> the Packages file, which in turn prompted the idea of per-flavour
> repositories.
>
> If you look at the whole idea though, you find out that it is a really neat
> solution to this problem, it cares for all the technical hurdles, and is
> elegant and nice, and if you throw in the part that can be automated, it saves
> work for everyone involved.

Say you do get your per flavour split despite increasing the number of
kernel modules worst arch has to deal with by a factor of 8 and for
most archs a factor of 40.

Can you imaging the poor users of a low-mem system going through the
list of 200+ components to pick out the right modules to download?
Neat?

> In my book, this makes it a good idea, or at least something that should be
> tried, and not something you have to menace the implementator so he doesn't
> dare pursue it.
>
>> So all I'm left with is that you don't end up with as much modules in
>> the ramdisk. Something I find irelevant unless you talk about the
>> low-mem flavour.
>
> And the fact that it is much easier to update config option and add and remove
> new modules doesn't count. Naturally, you don't handle kernel .udebs. I did,
> and it was a royal pain in the ass to handle those, it took me hours, for
> stuff that was already done 10 times for the other flavours. And even a few
> days ago, the powerpc64 flavour was still broken with the 2.6.17 kernels,
> because some random module listed in the list of modules was not present.
>
> The whole concept is of an extreme fragility, prone to break again and again,
> cause lot of work for all involved, who become irritable, and bash on you when
> you even mention it.

I did it when working on the amd64 D-I for sarge. I found it quite
trivial to do, a matter of minutes. In fact a hell of a lot simpler
and way faster than getting the linux-2.6 source package to do
something for me.

The kernel-wedge lists do break from time to time but they are simple
to adjust and quick to rebuild.

And another advantage with kernel-wedge: You can easily take your
(maybe even prebuild) custom kernel and create udebs from it. I would
hate to have to add the SuSe or RH patch sets to the linux-2.6 source
to build kernel udebs for hardware that requires their patches.

> This, in my book, is not an example of good software engineering, and any
> proposal to help improve this should be worth considering.

Still not convinced. You do have some points but I see more drawbacks
and problems than advantages.

>> Is

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Thomas Bushnell BSG]

Goswin von Brederlow <[EMAIL PROTECTED]> writes:

> Is it an aggregation with the image linked into the binary?

It doesn't matter for Debian's purposes.

While the GPL permits shipping a GPL'd program "merely aggregated"
alongside a non-free program, we don't ship the nonfree part no matter
what, so it hardly matters to us whether it's also a GPL violation.

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Sven Luther]

On Sun, Aug 13, 2006 at 03:47:13AM +0200, Goswin von Brederlow wrote:
> > The whole concept is of an extreme fragility, prone to break again and 
> > again,
> > cause lot of work for all involved, who become irritable, and bash on you 
> > when
> > you even mention it.
> 
> I did it when working on the amd64 D-I for sarge. I found it quite
> trivial to do, a matter of minutes. In fact a hell of a lot simpler
> and way faster than getting the linux-2.6 source package to do
> something for me.

Naturally, amd64 being one of the mainstream arches the d-i team cares about.

Now, please provide patches for resurecting the apus flavour, and then we can
speak again.

> 
> The kernel-wedge lists do break from time to time but they are simple
> to adjust and quick to rebuild.
> 
> And another advantage with kernel-wedge: You can easily take your
> (maybe even prebuild) custom kernel and create udebs from it. I would
> hate to have to add the SuSe or RH patch sets to the linux-2.6 source
> to build kernel udebs for hardware that requires their patches.

This could be easily be solved by adding the module info to the source package
in some way, or even integrate them into kernel-package.

> > This, in my book, is not an example of good software engineering, and any
> > proposal to help improve this should be worth considering.
> 
> Still not convinced. You do have some points but I see more drawbacks
> and problems than advantages.

At least you had the honestity to discuss it, while other rejected it out of
hand, with patronizing and aggresive language.

> >> Is the space taken up by the installed modules your actual argument
> >> for having finer grained module udebs?
> >
> > Nope, but then i told you that in the first mail already :)
> 
> Then you have presented no argument for splitting the module udebs and
> several against.

Several ?

> You do have raised some points of improvement for kernel-wedge. Like
> automaticaly adjusting to changed .config files or some other magics
> you mentioned. And some points for building module udebs from within
> linux-2.6 source although I don't agree with you there.

Why not ? It is the only way we can bring down the delay for security builds
with abi change to the minimum time, and the less human intervention.

> > The d-i team only needs to handle a list of the modules it want to include 
> > in
> > this or that ramdisk, and all will work automatically.
> 
> Which has the same problem as the kernel-wedge configuration has now
> when splitting the modules. When a module gets added or removed the
> list has to be adjusted.

Err, no, because the list would be handled in the debian-installer package or
its devel tree in the svn repo, and not inside kernel-wedge.

Notice that we already have the mapping of module .udeb packages to d-i images
in d-i proper, which needs to be done anyway in addition to the
kernel-wedge/linux-xxx-di work.

Furthermore with the current situation, and given that not all modules are
built the same on all arches, and that binary size vary per arch, you end up
in an unholy mess when trying to build space constrained ramdisks, like the
floppy ones for example.

> > Compared to the current situation, where the kernel porters have to update 
> > the
> > config files, then build the kernel .deb, they have to pass NEW, then the 
> > d-i
> 
> Still has to happen.

Indeed, but that is the only part that needs to be done, not the rest.

> > porters update the the kernel .udeb packages (one per arch), and the list of
> 
> Which is mostly just a new upload.

WRONG. it is at best an upload *PER ARCH*, done by *ONE DIFFERENT PERSON AT A
DIFFERENT TIME* for each arch. 

Furthermore, the build, failure, check what the heck kernel module has changed
name or dissapeared, or whatnot, is a *ROYAL PAIN*, and very much time
consuming., especially on slow arches with lot of flavours.

Furthermore, given that you need to install the kernel image package, you
can't even start to autobuild that without hosing the autobuilders.

> > modules which need to go into each ramdisk flavour, not mentioning that the
> 
> Which is pretty constant from my experience since the modules are
> already split right into udebs.

They are split into the right .udebs for the x86 and other mainstream cases
the kernel-wedge maintainer cares about.

> > ramdisk package list has no support for per-flavour module selection, and 
> > you
> > have to end up with stuff like the netboot64 list, which has as sole usage 
> > to
> > add the ibm power hypervisor and virtualization modules, all an ugly mess.
> 
> Something to improve. No argument for or against your proposal.

Because you miss that my proposal makes this whole issue obsolet and
non-existent.

> > So, the new proposal would mean the porters decide which config options (and
> > thus which modules), should be built, as well, in conjunction with the d-i
> > folk, which of those modules may be usefull for d-i, disks, networks, input
> > devices, dis

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[maximilian attems]

On Sat, Aug 12, 2006 at 09:53:48PM -0700, Thomas Bushnell BSG wrote:
> Goswin von Brederlow <[EMAIL PROTECTED]> writes:
> 
> > Is it an aggregation with the image linked into the binary?
> 
> It doesn't matter for Debian's purposes.
> 
> While the GPL permits shipping a GPL'd program "merely aggregated"
> alongside a non-free program, we don't ship the nonfree part no matter
> what, so it hardly matters to us whether it's also a GPL violation.
> 
> Thomas

stop abusing debian-kernel, this thread is pointless.
either you contribute as already pointed out by Md and fs
or you may want start whining at other places.

--
maks

ps stripped debian-release ml from cc:
i'm not a d-release regular, but i fail to see any posted relevance.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Jonas Smedegaard]

On Sun, 13 Aug 2006 10:39:18 +0200 maximilian attems wrote:

> stop abusing debian-kernel, this thread is pointless.


I disagree.

Thanks especially to Goswin and Sven for your honest attempt at
reaching a common understanding in these matters. It is certainly
relevant, and although all the arguments in this thread may already be
raised before, they were scattered across time and lists and (even more
than here) cluttered with whining.


Kind regards,

 - Jonas


-- 
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

 - Enden er nær: http://www.shibumi.org/eoti.htm


pgp1EtEIbyYY7.pgp
Description: PGP signature

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Goswin von Brederlow]

Sven Luther <[EMAIL PROTECTED]> writes:

> On Sat, Aug 12, 2006 at 11:03:29PM +0200, Goswin von Brederlow wrote:
>> Compare it to including a hexdump of an image or sound in a header
>> file and including that in the binary. And compare it with having that
>> same image or sound as external file shipped in the same deb.
>
> Well, the FSF argues that it is not important where the file is, as long as
> there is a logical link, in order to have the GPL cross the dynamic linking
> barrier. In the same way, the only relationship of the non-free firmware or
> your image or sound, is that it is transported in the same binary, and used as
> data offloaded to the peripheral device.
>
>> Assume the image/sound was rendered/generated from some source format
>> not included in the source. E.g. povray input.
>
> So ? What has this to do with it ? 

So you can't claim the hexdump (or binary file) is the prefered form
of modification (source).

>> Is it an aggregation with the image linked into the binary?
>
> It depends if your binary is an image compressor, and only transports the
> image, or if said image is used in the binary for icons of its GUI for example
> or as splash screen.

If I just dump my hexcode of the image/sound to my black box (qiv or
xmms for example) for (dis)playing then I only transport the file. If
I (dis)play it myself then it isn't an aggregation. Intresting.

Or does the black box have to be hardware?

>> >> "aggregated" code from the kernel image?
>> > Not relevant.
>> 
>> If it is an aggregation then there must be a way to break it up and
>> only keep the GPLed parts. I think that is very much relevant. I don't
>> think you can call something an aggregation if it is inseperably bound
>> together.
>
> Well, sure there is part to separate them. You could imagine a (non-free) tool
> called before lilo or grub, and which would upload those firmwares for the
> peripheral device to be ready when the free driver comes into play.

I can imagine a tool that rewrites non-free parts of a binary as free
software from scratch without breaking any laws about reverse
engeneering too. Does that mean they exist or are even possible? no.

> Or you could use the new initramfs/firmware loading kernel infrastructure to
> separate the firmware from the kernel.

That requires changes in the source. Exactly those changes is what I
say must happen. The firmware loading kernel infrastructure marks a
clear lines where an external blob of firmware gets loaded that isn't
part of the kernel binary itself.

> Err, is not this latest one what you are suggesting we do ? So, if i
> understood you well, your own argumentation is hitting you back there, and
> this is usually proof that there is something terribly wrong in your
> argumentation to start with.

No. You just argumented my point. The source changes to seperate the
firmware and to use the firmware loading kernel infrastructure makes a
difference imho.

Also notice that with the firmware loading kernel infrastructure you
can just delete the firmware file and the loader will give a simple
error. Good luck trying to remove the char *firmware from a kernel
image and not have it crash. Best you can do there is fill it with
dummy data.

> Friendly,
>
> Sven Luther

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Sven Luther]

On Sun, Aug 13, 2006 at 04:01:12AM +0200, Goswin von Brederlow wrote:
> Sven Luther <[EMAIL PROTECTED]> writes:
> 
> > On Sat, Aug 12, 2006 at 11:03:29PM +0200, Goswin von Brederlow wrote:
> >> Compare it to including a hexdump of an image or sound in a header
> >> file and including that in the binary. And compare it with having that
> >> same image or sound as external file shipped in the same deb.
> >
> > Well, the FSF argues that it is not important where the file is, as long as
> > there is a logical link, in order to have the GPL cross the dynamic linking
> > barrier. In the same way, the only relationship of the non-free firmware or
> > your image or sound, is that it is transported in the same binary, and used 
> > as
> > data offloaded to the peripheral device.
> >
> >> Assume the image/sound was rendered/generated from some source format
> >> not included in the source. E.g. povray input.
> >
> > So ? What has this to do with it ? 
> 
> So you can't claim the hexdump (or binary file) is the prefered form
> of modification (source).

Well, i never argued that, i always said that the binary-only firmwares
without source, are non-DFSG-free, and should be handled accordyingly.

The point is that they are not considered a derivative work of the kernel
source, and thus that the presence of non-free firmware inside the kernel
binary is no breakage of the kernel GPL.

> >> Is it an aggregation with the image linked into the binary?
> >
> > It depends if your binary is an image compressor, and only transports the
> > image, or if said image is used in the binary for icons of its GUI for 
> > example
> > or as splash screen.
> 
> If I just dump my hexcode of the image/sound to my black box (qiv or
> xmms for example) for (dis)playing then I only transport the file. If
> I (dis)play it myself then it isn't an aggregation. Intresting.

If the image is integral part of your program, it being non-free breaks the
GPL of your program, independently of it being included in the same binary or
not.

displaying some random image doesn't count as 'being integral part of the
program'.

> Or does the black box have to be hardware?

nope, the same applies in all case, but i wish you would not mix the problems
and provide false argumentation for the case we agree with, in order to
disproof a totally different issue.

> >> >> "aggregated" code from the kernel image?
> >> > Not relevant.
> >> 
> >> If it is an aggregation then there must be a way to break it up and
> >> only keep the GPLed parts. I think that is very much relevant. I don't
> >> think you can call something an aggregation if it is inseperably bound
> >> together.
> >
> > Well, sure there is part to separate them. You could imagine a (non-free) 
> > tool
> > called before lilo or grub, and which would upload those firmwares for the
> > peripheral device to be ready when the free driver comes into play.
> 
> I can imagine a tool that rewrites non-free parts of a binary as free
> software from scratch without breaking any laws about reverse
> engeneering too. Does that mean they exist or are even possible? no.

Well, what is a bios apart from a tool which runs at system startup and
initialises the peripheral procesors in a state which will allow later
programs to use it ? I do bios/firmware writing for a living, and plan to
embedd exactly such non-free firmware into the flash firmware of my board, to
power onboard devices that need them.

So, again, what was your argumentation here ? 

> > Or you could use the new initramfs/firmware loading kernel infrastructure to
> > separate the firmware from the kernel.
> 
> That requires changes in the source. Exactly those changes is what I
> say must happen.

Indeed. and i *NEVER* said that they should not happen, i *NEVER said that
this was the point we are discussing, i actually *AGREE* with you there. This
is a fully orthogonal issue to the aggregate work status of the firmwares in
question with regard to the kernel.

So, now that we agreed that those modules need to go into non-free, but that
provided their licence is clear enough, like in the tg3 case, they are indeed
distriutable in non-free, let's go back to the initial point.

This is upstream work, and work which is slowly happening upstream, but will
never be ready in time for the etch release. The kernel team has not the
ressources to do all that work in a timely fashion for the stated etch
release, and delaying until it is ready may mean at least a year of delay for
the etch release, which is unacceptable for many.

So, if you are really concerned about this issue, start coding, we await your
patches impatiently, and will even help you bring them upstream, so they may
be integrated in the current debian kernels accordying to our current policy.

> The firmware loading kernel infrastructure marks a
> clear lines where an external blob of firmware gets loaded that isn't
> part of the kernel binary itself.

Well, i would say that a single variable symbol is as 

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Goswin von Brederlow]

Sven Luther <[EMAIL PROTECTED]> writes:

> So, now that we agreed that those modules need to go into non-free, but that
> provided their licence is clear enough, like in the tg3 case, they are indeed
> distriutable in non-free, let's go back to the initial point.
>
> This is upstream work, and work which is slowly happening upstream, but will
> never be ready in time for the etch release. The kernel team has not the
> ressources to do all that work in a timely fashion for the stated etch
> release, and delaying until it is ready may mean at least a year of delay for
> the etch release, which is unacceptable for many.

Upstream is not doing it and Debian has written it on their flag (DFSG
and SC) to get it done. That means Debian has to do it. If that means
etch will be delayed a year then etch will be delayed one year. THAT
fact was the begining of the thread. Showing that the kernel is not
ready to be frozen in accordance to the timeline because the firmware
is still not removed.

If you can't live with that delay then please start a GR to get an
exemption like sarge had. I don't think there has to be more arguing
about it anymore.

> Friendly,
>
> Sven Luther

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Goswin von Brederlow]

Sven Luther <[EMAIL PROTECTED]> writes:

> On Sun, Aug 13, 2006 at 03:47:13AM +0200, Goswin von Brederlow wrote:
>> > The whole concept is of an extreme fragility, prone to break again and 
>> > again,
>> > cause lot of work for all involved, who become irritable, and bash on you 
>> > when
>> > you even mention it.
>> 
>> I did it when working on the amd64 D-I for sarge. I found it quite
>> trivial to do, a matter of minutes. In fact a hell of a lot simpler
>> and way faster than getting the linux-2.6 source package to do
>> something for me.
>
> Naturally, amd64 being one of the mainstream arches the d-i team cares about.

No they didn't since amd64 was not official or even liked. It didn't
even exist before I cloned the i386 config and adjusted them to fit.

> Now, please provide patches for resurecting the apus flavour, and then we can
> speak again.
>
>> 
>> The kernel-wedge lists do break from time to time but they are simple
>> to adjust and quick to rebuild.
>> 
>> And another advantage with kernel-wedge: You can easily take your
>> (maybe even prebuild) custom kernel and create udebs from it. I would
>> hate to have to add the SuSe or RH patch sets to the linux-2.6 source
>> to build kernel udebs for hardware that requires their patches.
>
> This could be easily be solved by adding the module info to the source package
> in some way, or even integrate them into kernel-package.

Into the SuSe/RH source? Not likely. And kernel-package doesn't deal
with prebuild binaries.

>> > This, in my book, is not an example of good software engineering, and any
>> > proposal to help improve this should be worth considering.
>> 
>> Still not convinced. You do have some points but I see more drawbacks
>> and problems than advantages.
>
> At least you had the honestity to discuss it, while other rejected it out of
> hand, with patronizing and aggresive language.
>
>> >> Is the space taken up by the installed modules your actual argument
>> >> for having finer grained module udebs?
>> >
>> > Nope, but then i told you that in the first mail already :)
>> 
>> Then you have presented no argument for splitting the module udebs and
>> several against.
>
> Several ?
>
>> You do have raised some points of improvement for kernel-wedge. Like
>> automaticaly adjusting to changed .config files or some other magics
>> you mentioned. And some points for building module udebs from within
>> linux-2.6 source although I don't agree with you there.
>
> Why not ? It is the only way we can bring down the delay for security builds
> with abi change to the minimum time, and the less human intervention.

I don't see security for the installer as a top priority. It is not
like people will burn their daily security patched D-I image. It is
not like the security team does do security releases for D-I. For
stable that seems to get totaly ignored.

D-I in testing/sid, especially the daylies, are for developing. Not to
run a secure and stable system. The have bugs, they have security
flaws, they might not work at all. That is what unstable is.

>> > The d-i team only needs to handle a list of the modules it want to include 
>> > in
>> > this or that ramdisk, and all will work automatically.
>> 
>> Which has the same problem as the kernel-wedge configuration has now
>> when splitting the modules. When a module gets added or removed the
>> list has to be adjusted.
>
> Err, no, because the list would be handled in the debian-installer package or
> its devel tree in the svn repo, and not inside kernel-wedge.

Moving the problem from A to B. Doesn't matter what svn repository it
is in.

> Notice that we already have the mapping of module .udeb packages to d-i images
> in d-i proper, which needs to be done anyway in addition to the
> kernel-wedge/linux-xxx-di work.
>
> Furthermore with the current situation, and given that not all modules are
> built the same on all arches, and that binary size vary per arch, you end up
> in an unholy mess when trying to build space constrained ramdisks, like the
> floppy ones for example.

That just means that you need per arch lists of modules. And
kernel-wedge has that. Having each module as udeb doesn't change the
fact that you have a unholy mess what modules to put in the image.

>> > Compared to the current situation, where the kernel porters have to update 
>> > the
>> > config files, then build the kernel .deb, they have to pass NEW, then the 
>> > d-i
>> 
>> Still has to happen.
>
> Indeed, but that is the only part that needs to be done, not the rest.
>
>> > porters update the the kernel .udeb packages (one per arch), and the list 
>> > of
>> 
>> Which is mostly just a new upload.
>
> WRONG. it is at best an upload *PER ARCH*, done by *ONE DIFFERENT PERSON AT A
> DIFFERENT TIME* for each arch. 
>
> Furthermore, the build, failure, check what the heck kernel module has changed
> name or dissapeared, or whatnot, is a *ROYAL PAIN*, and very much time
> consuming., especially on slow arches with lot of flavou

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Joey Hess]

Goswin von Brederlow wrote:
> > ramdisk package list has no support for per-flavour module selection, and 
> > you
> > have to end up with stuff like the netboot64 list, which has as sole usage 
> > to
> > add the ibm power hypervisor and virtualization modules, all an ugly mess.
> 
> Something to improve. No argument for or against your proposal.

I thought I'd respond to this, not because it's the first case of Sven
posting incorrect information to this thread, but because it's one of
the more egrarious.

Quoting debian-installer/build/README:

* 'pkg-lists' has subdirectories for the different image types that list
  udebs that are put on each image. The pkg-lists/*/common files list
  udebs common to all architectures, and the files named by architecture
  (.cfg) list udebs specific to an architecture. It is also possible
  to include udebs only on a specific subarchitecture by creating a
  directory for the architecture and putting config files for the
  subarchitecture there (/.cfg).

If you take a look at pkg-lists/netboot, you'll find things like:

[EMAIL PROTECTED]:~/src/d-i/installer/build/pkg-lists/netboot/arm>l
ads.cfg  netwinder.cfg  nslu2.cfg
[EMAIL PROTECTED]:~/src/d-i/installer/build/pkg-lists/netboot/sparc>l
combined.cfg  sparc32.cfg  sparc64.cfg
[EMAIL PROTECTED]:~/src/d-i/installer/build/pkg-lists/netboot/mipsel>l
bcm947xx.cfg  cobalt.cfg  r3k-kn02.cfg  r4k-kn04.cfg  sb1-bcm91250a.cfg

In fact, powerpc is the only architecture to use unnecessary hacks like
netboot64, cdrom64, and netboot-apus.

I'd be very happy if someone who cares about powerpc subarches and can read
and understand documentation like the above could clean this up (if such a
person exists).

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Sven Luther]

On Sun, Aug 13, 2006 at 07:14:02PM +0200, Goswin von Brederlow wrote:
> Sven Luther <[EMAIL PROTECTED]> writes:
> 
> > On Sun, Aug 13, 2006 at 03:47:13AM +0200, Goswin von Brederlow wrote:
> >> > The whole concept is of an extreme fragility, prone to break again and 
> >> > again,
> >> > cause lot of work for all involved, who become irritable, and bash on 
> >> > you when
> >> > you even mention it.
> >> 
> >> I did it when working on the amd64 D-I for sarge. I found it quite
> >> trivial to do, a matter of minutes. In fact a hell of a lot simpler
> >> and way faster than getting the linux-2.6 source package to do
> >> something for me.
> >
> > Naturally, amd64 being one of the mainstream arches the d-i team cares 
> > about.
> 
> No they didn't since amd64 was not official or even liked. It didn't
> even exist before I cloned the i386 config and adjusted them to fit.

Let's say that the amd64 arch is very very near the x86 one in design. After
all it is just a followup of the later.

> Into the SuSe/RH source? Not likely. And kernel-package doesn't deal
> with prebuild binaries.

kernel-package deals with creating kernel .debs. You need kernel .debs to use
kernel-wedge, at least this is the way it is designed to work, so you lose
nothing there.

> >> You do have raised some points of improvement for kernel-wedge. Like
> >> automaticaly adjusting to changed .config files or some other magics
> >> you mentioned. And some points for building module udebs from within
> >> linux-2.6 source although I don't agree with you there.
> >
> > Why not ? It is the only way we can bring down the delay for security builds
> > with abi change to the minimum time, and the less human intervention.
> 
> I don't see security for the installer as a top priority. It is not
> like people will burn their daily security patched D-I image. It is
> not like the security team does do security releases for D-I. For
> stable that seems to get totaly ignored.

Indeed, but this is mostly because due to those issues they are incapable of
handling those security issues in a timely fashion.

> D-I in testing/sid, especially the daylies, are for developing. Not to
> run a secure and stable system. The have bugs, they have security
> flaws, they might not work at all. That is what unstable is.

My main problem is that sarge released with a remote root security hole,
which was known and publicized a few month before the actual release, which
means all sarge systems are potentially unsecure.

> >> > The d-i team only needs to handle a list of the modules it want to 
> >> > include in
> >> > this or that ramdisk, and all will work automatically.
> >> 
> >> Which has the same problem as the kernel-wedge configuration has now
> >> when splitting the modules. When a module gets added or removed the
> >> list has to be adjusted.
> >
> > Err, no, because the list would be handled in the debian-installer package 
> > or
> > its devel tree in the svn repo, and not inside kernel-wedge.
> 
> Moving the problem from A to B. Doesn't matter what svn repository it
> is in.

Yes, it does matter. If it is inside kernel-wedge, you need to upload kernel
wedge to benefit from any fix, while if it is in d-i, you can just build the
out-of-svn tree and be happy.

> > Notice that we already have the mapping of module .udeb packages to d-i 
> > images
> > in d-i proper, which needs to be done anyway in addition to the
> > kernel-wedge/linux-xxx-di work.
> >
> > Furthermore with the current situation, and given that not all modules are
> > built the same on all arches, and that binary size vary per arch, you end up
> > in an unholy mess when trying to build space constrained ramdisks, like the
> > floppy ones for example.
> 
> That just means that you need per arch lists of modules. And
> kernel-wedge has that. Having each module as udeb doesn't change the

Kernel-wedge has no per arch list of modules, those are in the 12+ individual
linux-*-di packages.

> fact that you have a unholy mess what modules to put in the image.

You don't have an unholy mess, since you can select exactly what modules need
to go into each image, a simple list or a hierarchical per
arch/subarch/flavour list. Compared to the current case, where you have to
upload two packages to be able to modify the list included in d-i.

> > Furthermore, the build, failure, check what the heck kernel module has 
> > changed
> > name or dissapeared, or whatnot, is a *ROYAL PAIN*, and very much time
> > consuming., especially on slow arches with lot of flavours.
> 
> A factor of 1 or so faster than building the linux-2.6 source. As
> combined time the kernel-wedge time is neglible.

Ah, but the beauty of my proposal is that you have tool which handles the
config files and module-as-udebs without needing to do a full build. Like
Bastian created the nice debian/rules target to check all config options.

> > Furthermore, given that you need to install the kernel image package, you
> > can't even start to aut

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Sven Luther]

On Sun, Aug 13, 2006 at 02:26:20PM -0400, Joey Hess wrote:
> Goswin von Brederlow wrote:
> > > ramdisk package list has no support for per-flavour module selection, and 
> > > you
> > > have to end up with stuff like the netboot64 list, which has as sole 
> > > usage to
> > > add the ibm power hypervisor and virtualization modules, all an ugly mess.
> > 
> > Something to improve. No argument for or against your proposal.
> 
> I thought I'd respond to this, not because it's the first case of Sven
> posting incorrect information to this thread, but because it's one of
> the more egrarious.
> 
> Quoting debian-installer/build/README:
> 
> * 'pkg-lists' has subdirectories for the different image types that list
>   udebs that are put on each image. The pkg-lists/*/common files list
>   udebs common to all architectures, and the files named by architecture
>   (.cfg) list udebs specific to an architecture. It is also possible
>   to include udebs only on a specific subarchitecture by creating a
>   directory for the architecture and putting config files for the
>   subarchitecture there (/.cfg).
> 
> If you take a look at pkg-lists/netboot, you'll find things like:
> 
> [EMAIL PROTECTED]:~/src/d-i/installer/build/pkg-lists/netboot/arm>l
> ads.cfg  netwinder.cfg  nslu2.cfg
> [EMAIL PROTECTED]:~/src/d-i/installer/build/pkg-lists/netboot/sparc>l
> combined.cfg  sparc32.cfg  sparc64.cfg
> [EMAIL PROTECTED]:~/src/d-i/installer/build/pkg-lists/netboot/mipsel>l
> bcm947xx.cfg  cobalt.cfg  r3k-kn02.cfg  r4k-kn04.cfg  sb1-bcm91250a.cfg
> 
> In fact, powerpc is the only architecture to use unnecessary hacks like
> netboot64, cdrom64, and netboot-apus.

Ah, if i remember well, it was you (or Colin maybe ?), who suggested me the
netboot64 and cdrom64 as the only solution for that problem. I think since
then that the virtualization modules could be added to the normal
netboot/cdrom powerpc flavours, with the ? optional flag. This was not
existent when those flavours first got created though.

I was going to do that, but as you kicked me out of the d-i team ...

> I'd be very happy if someone who cares about powerpc subarches and can read
> and understand documentation like the above could clean this up (if such a
> person exists).

If even yourself are not able to understand it, and thus gives bogus advice, i
guess you will find nobody.

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Thomas Bushnell BSG]

maximilian attems <[EMAIL PROTECTED]> writes:

> On Sat, Aug 12, 2006 at 09:53:48PM -0700, Thomas Bushnell BSG wrote:
>> Goswin von Brederlow <[EMAIL PROTECTED]> writes:
>> 
>> > Is it an aggregation with the image linked into the binary?
>> 
>> It doesn't matter for Debian's purposes.
>> 
>> While the GPL permits shipping a GPL'd program "merely aggregated"
>> alongside a non-free program, we don't ship the nonfree part no matter
>> what, so it hardly matters to us whether it's also a GPL violation.
>> 
>> Thomas
>
> stop abusing debian-kernel, this thread is pointless.
> either you contribute as already pointed out by Md and fs
> or you may want start whining at other places.

It was complained that valid bugs of the sort "there is non-free
software here and here and here" were being closed summarily.

Was this accurate?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Goswin von Brederlow]

Sven Luther <[EMAIL PROTECTED]> writes:

> If even yourself are not able to understand it, and thus gives bogus advice, i
> guess you will find nobody.
>
> Sven Luther

Maybe the reason the now proper advice wasn't given to you was that
the feature did not exist back when you asked?

Or you asked the question in a way that didn't trigger the right
answere.


I highly doubt understanding of the kernel-wedge was at fault here.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Sven Luther]

On Tue, Aug 15, 2006 at 10:03:08AM +0200, Goswin von Brederlow wrote:
> Sven Luther <[EMAIL PROTECTED]> writes:
> 
> > If even yourself are not able to understand it, and thus gives bogus 
> > advice, i
> > guess you will find nobody.
> >
> > Sven Luther
> 
> Maybe the reason the now proper advice wasn't given to you was that
> the feature did not exist back when you asked?

Maybe, but then he should have said something such, and not started bashing on
me. 

> Or you asked the question in a way that didn't trigger the right
> answere.

I was given the advice to do it as i did, and now he comes critizing me.

> I highly doubt understanding of the kernel-wedge was at fault here.

The only thing at hand here, is indulging on another round of sven-bashing.

It is purely non-constructive, since he has me in his killfill anyway even.

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

[Goswin von Brederlow]

Sven Luther <[EMAIL PROTECTED]> writes:

> On Sun, Aug 13, 2006 at 07:14:02PM +0200, Goswin von Brederlow wrote:
>> Moving the problem from A to B. Doesn't matter what svn repository it
>> is in.
>
> Yes, it does matter. If it is inside kernel-wedge, you need to upload kernel
> wedge to benefit from any fix, while if it is in d-i, you can just build the
> out-of-svn tree and be happy.

And I can just as easily build the kernel-wedge out-of-svn. That
really makes no difference.

>> > Furthermore, the build, failure, check what the heck kernel module has 
>> > changed
>> > name or dissapeared, or whatnot, is a *ROYAL PAIN*, and very much time
>> > consuming., especially on slow arches with lot of flavours.
>> 
>> A factor of 1 or so faster than building the linux-2.6 source. As
>> combined time the kernel-wedge time is neglible.
>
> Ah, but the beauty of my proposal is that you have tool which handles the
> config files and module-as-udebs without needing to do a full build. Like
> Bastian created the nice debian/rules target to check all config options.

Which helps exactly 0 if you build all the kernels and then detect
that a module was not manualy maintained in the "to be udeb-ed"
list. Since not all modules are to be put in udebs I see no way how
you will automate the list.

And instead of having a 1 minute run of kernel-wedge to build the udeb
for the one generic kernel of most archs you have a 6h build of all
the (non D-I except for generic) flavours. Getting a module into an
udeb would be a hell  of a lot more time consuming.

>> > Furthermore, given that you need to install the kernel image package, you
>> > can't even start to autobuild that without hosing the autobuilders.
>> 
>> Last I use kernel-wedge, and this is ~2 years ago now, you could build
>> all kernel udebs on a single arch with the help of a little wrapper
>> script. Did somone break that?
>
> This has been rumored, but i have not seen this script, and the latest round
> of discussion during debconf/mexico, Frans rejected the idea of doing a single
> kernel .udeb package for all arches, claiming this was not possible, that it
> would break autobuilders who wanted to install the kernels and so on.
>
> But then, maybe he was isssuing clueless suppositions ?

The script was in the repository and was never for auto-building.

Buildds must install the kernel image package because a Build-Depends
is the only way to download a deb on a buildd. You can not rely on a
network connection during build so you can't download the debs some
other way. And since you can't install a s390 kernel on arm that makes
building for all archs impossible for buildds.

With a manual build you can just apt-get the debs and unpack them on
the spot without having to install anything.

>> Rewrite that script.
>
> Get ride of it and build the .udebs from the kernel packages :)
>
>> >> > modules which need to go into each ramdisk flavour, not mentioning that 
>> >> > the
>> >> 
>> >> Which is pretty constant from my experience since the modules are
>> >> already split right into udebs.
>> >
>> > They are split into the right .udebs for the x86 and other mainstream cases
>> > the kernel-wedge maintainer cares about.
>> 
>> Even if they are not split right you don't change what udebs go into
>> the ramdisk. You fix the split itself (which you already have to do,
>> that work is already accounted for). So this part of the job is a NOP.
>
> Ah, but the interesting part of it comes when the constraint for x86 floppies
> and powerpc floppies for example impose different distribution of modules.

That is why each arch has possibly different modules listed. And as
Joeyh posted even per flavour. This is really a non problem solve
years ago.

> As an example, i was not able to build apus flavoured .udebs, since i don't
> remember which .udeb included a module not built on apus, and which needed
> kernel-wedge modifications, which Frans forbade me to make.

You were forbidden to do it. It wasn't impossible or even difficult.

>> >> > ramdisk package list has no support for per-flavour module selection, 
>> >> > and you
>> >> > have to end up with stuff like the netboot64 list, which has as sole 
>> >> > usage to
>> >> > add the ibm power hypervisor and virtualization modules, all an ugly 
>> >> > mess.
>> >> 
>> >> Something to improve. No argument for or against your proposal.
>> >
>> > Because you miss that my proposal makes this whole issue obsolet and
>> > non-existent.
>> 
>> No it doesn't. You still have to list the modules that get into the
>> ramdisk. That list doesn't magically build itself just because you
>> parse .config.
>
> Again, you fail to understand. In the current case, you do the work 3 times :
>
>   1) the kernel team choses the configuration option for the kernel, and thus
>   chose which modules to enable or not.

Which is a trivial step as they basicaly enable all modules and hardly
ever disable one again.

>   2) the kernel-wedge contains a list of mo