On Tue, Oct 10, 2006 at 09:51:32PM +0200, Sven Luther wrote:
i now release the call for vote, and ask for a vote to be held with the
original proposal from Frederik, which has had enough seconds since August 31.
As a point of order, the original proposal from Frederik was superseded once
he
On Tue, Oct 10, 2006 at 09:20:37PM -0500, Steve Langasek wrote:
On Tue, Oct 10, 2006 at 09:51:32PM +0200, Sven Luther wrote:
i now release the call for vote, and ask for a vote to be held with the
original proposal from Frederik, which has had enough seconds since August
31.
As a point
On Thu, Sep 28, 2006 at 05:02:13PM +0200, Frederik Schueler wrote:
Hi,
On Wed, Sep 27, 2006 at 06:40:41PM +0200, Kurt Roeckx wrote:
2. We acknowledge that there is a lot of progress in the kernel firmware
issue; however, it is not yet finally sorted out;
So, what progress has been
On Thu, Sep 28, 2006 at 05:02:13PM +0200, Frederik Schueler wrote:
Hi,
On Wed, Sep 27, 2006 at 06:40:41PM +0200, Kurt Roeckx wrote:
2. We acknowledge that there is a lot of progress in the kernel firmware
issue; however, it is not yet finally sorted out;
So, what progress has been
On Wed, Sep 27, 2006 at 04:56:40PM +, Sune Vuorela wrote:
On 2006-09-27, Kurt Roeckx [EMAIL PROTECTED] wrote:
On Wed, Sep 27, 2006 at 11:36:37AM +0200, Frederik Schueler wrote:
2. We acknowledge that there is a lot of progress in the kernel firmware
issue; however, it is not yet finally
On Thu, Sep 28, 2006 at 11:48:49AM +0200, Sven Luther wrote:
On Wed, Sep 27, 2006 at 04:56:40PM +, Sune Vuorela wrote:
On 2006-09-27, Kurt Roeckx [EMAIL PROTECTED] wrote:
On Wed, Sep 27, 2006 at 11:36:37AM +0200, Frederik Schueler wrote:
2. We acknowledge that there is a lot of
Hi,
On Wed, Sep 27, 2006 at 06:40:41PM +0200, Kurt Roeckx wrote:
2. We acknowledge that there is a lot of progress in the kernel firmware
issue; however, it is not yet finally sorted out;
So, what progress has been made?
For example:
- the firmware_class infrastructure has been added in
Hello,
On Tue, Sep 26, 2006 at 04:02:11PM -0700, Steve Langasek wrote:
As I mentioned previously, I don't think point 3. here is the compromise I
would like to see. Without further conditions is so broad that it seems
to even *require* us to include firmware in main that lacks any sort of
On Wed, Sep 27, 2006 at 11:36:37AM +0200, Frederik Schueler wrote:
Hello,
On Tue, Sep 26, 2006 at 04:02:11PM -0700, Steve Langasek wrote:
As I mentioned previously, I don't think point 3. here is the compromise I
would like to see. Without further conditions is so broad that it seems
to
On Wed, Sep 27, 2006 at 11:36:37AM +0200, Frederik Schueler wrote:
Hello,
On Tue, Sep 26, 2006 at 04:02:11PM -0700, Steve Langasek wrote:
As I mentioned previously, I don't think point 3. here is the compromise I
would like to see. Without further conditions is so broad that it seems
to
On 2006-09-27, Kurt Roeckx [EMAIL PROTECTED] wrote:
On Wed, Sep 27, 2006 at 11:36:37AM +0200, Frederik Schueler wrote:
2. We acknowledge that there is a lot of progress in the kernel firmware
issue; however, it is not yet finally sorted out;
So, what progress has been made?
All firmwarez
On Tue, Sep 26, 2006 at 10:41:24AM +0200, Sven Luther wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
As seconder of the below proposal, which has reached enough seconds since
august 31, and as there where no ammendments against this proposal, i now
officially call for a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
As seconder of the below proposal, which has reached enough seconds since
august 31, and as there where no ammendments against this proposal, i now
officially call for a vote, as per section A.2 of our constitution.
On Tue, Sep 26, 2006 at 10:41:24AM +0200, Sven Luther wrote:
As seconder of the below proposal, which has reached enough seconds since
august 31, and as there where no ammendments against this proposal, i now
officially call for a vote, as per section A.2 of our constitution.
Manoj, ...
This issue remains, and it is still not solved. This has got the approval of
Steve Langasek (who said that his proposal and this where orthogonal and a
separate GR), of our DPL, who said he would postpone his own GR proposal for
post etch, as well as the proposer of this GR.
There
Hello,
On Sun, Sep 10, 2006 at 02:16:26AM -0700, Steve Langasek wrote:
I asked you this question before privately and haven't seen an answer. You
say below So we propose this GR:; does that mean that everything up to
that is rationale, and not part of the text that developers will be voting
Steve wrote:
So if we are going to make an exception, I think we should take care to
make the smallest exception necessary.
I hope everyone here can agree with that.
If we don't *need* to grant exceptions
for firmware based on their license, only on whether or not they include
source, I
Hi Frederik,
On Wed, Aug 30, 2006 at 11:06:54PM +0200, Frederik Schueler wrote:
Overview:
I asked you this question before privately and haven't seen an answer. You
say below So we propose this GR:; does that mean that everything up to
that is rationale, and not part of the text that
On Sun, Sep 10, 2006 at 02:16:26AM -0700, Steve Langasek wrote:
Hi Frederik,
On Wed, Aug 30, 2006 at 11:06:54PM +0200, Frederik Schueler wrote:
Overview:
I asked you this question before privately and haven't seen an answer. You
say below So we propose this GR:; does that mean that
On Sat, Sep 09, 2006 at 01:57:31AM -0400, Nathanael Nerode wrote:
The arsenic case was more problematic, since the copyright seems to have
landed at broadcom too, but they don't care since they don't sell it
anymore,
Given this, we actually should have a decent chance of getting them to
On Thu, Sep 07, 2006 at 05:08:28PM -0500, Bill Allombert wrote:
On Fri, Sep 01, 2006 at 02:42:26PM -0400, Raul Miller wrote:
What strikes me as ironic, with these proposals, is that we ran into
something like this problem back in the 90s, back during the initial
adoption of the DFSG, and we
On 9/8/06, Sven Luther [EMAIL PROTECTED] wrote:
On Thu, Sep 07, 2006 at 05:08:28PM -0500, Bill Allombert wrote:
On Fri, Sep 01, 2006 at 02:42:26PM -0400, Raul Miller wrote:
Perhaps we should start addressing the CD distributor problem (perhaps
tagging CD distributable software, and
On Fri, Sep 08, 2006 at 11:20:43AM -0400, Raul Miller wrote:
On 9/8/06, Sven Luther [EMAIL PROTECTED] wrote:
On Thu, Sep 07, 2006 at 05:08:28PM -0500, Bill Allombert wrote:
On Fri, Sep 01, 2006 at 02:42:26PM -0400, Raul Miller wrote:
Perhaps we should start addressing the CD distributor
Anthony Towns wrote:
On Thu, Aug 31, 2006 at 12:48:35AM -0400, Nathanael Nerode wrote:
Actually, this is what is wrong with the polls at the debian user forums
which AJ pointed people to. Etch can release on time either free (with
less hardware support) or non-free (with more hardware
Diverting to -legal.
Sven Luther wrote:
On Thu, Aug 31, 2006 at 12:48:35AM -0400, Nathanael Nerode wrote:
Sven Luther wrote:
Yeah, that is something which is needed. We need someone to go over
larry's list, which i have copiedto the debian wiki, and find out who
the copyright holder of
On Sep 07, Thomas Bushnell BSG [EMAIL PROTECTED] wrote:
The widely accepted custom was to interpret the DFSG this way, yes.
This is what matters.
What is your evidence of this?
My experience of 9 years in Debian, which can be verified by browsing
the list archives.
--
ciao,
Marco
[EMAIL PROTECTED] (Marco d'Itri) writes:
On Sep 07, Thomas Bushnell BSG [EMAIL PROTECTED] wrote:
The widely accepted custom was to interpret the DFSG this way, yes.
This is what matters.
What is your evidence of this?
My experience of 9 years in Debian, which can be verified by browsing
[EMAIL PROTECTED] wrote:
I have not been the only one to be upset about the firmware situation
every time it has been brought up, as can be verified by browsing the
list archives. I can see that the controversy is old, but certainly
not that your interpretation was widely accepted.
Wrong. The
On Fri, Sep 01, 2006 at 02:42:26PM -0400, Raul Miller wrote:
What strikes me as ironic, with these proposals, is that we ran into
something like this problem back in the 90s, back during the initial
adoption of the DFSG, and we had to solve that problem then:
we created the non-free and
On Wed, Sep 06, 2006 at 12:11:08PM +1000, Anthony Towns wrote:
On Tue, Sep 05, 2006 at 05:54:25PM +0200, Sven Luther wrote:
We are quickly reaching the point where holding a vote on this issue and
still
maintaining a timely etch release, so i believe that we should held a vote
on
this
On Sep 06, Thomas Bushnell BSG [EMAIL PROTECTED] wrote:
No, it's a contentious issue because some people are trying hard to
change the values of Debian replacing what was a compromise widely
accepted by everybody in Debian and most people outside Debian with
mindlessly following their
Thomas Bushnell BSG wrote:
Right. And the problem is that the d-i team seems to say to
themselves, as long as we never do the work, we can badger the rest
of Debian into sacrificing the Project's principles, and the work will
never be necessary.
Um, no.
a) I told people at DebConf that I
On Wed, Sep 06, 2006 at 09:03:14AM +0200, Sven Luther wrote:
On Wed, Sep 06, 2006 at 12:11:08PM +1000, Anthony Towns wrote:
On Tue, Sep 05, 2006 at 05:54:25PM +0200, Sven Luther wrote:
We are quickly reaching the point where holding a vote on this issue and
still
maintaining a timely
On Wed, Sep 06, 2006 at 10:56:58PM +1000, Anthony Towns wrote:
On Wed, Sep 06, 2006 at 09:03:14AM +0200, Sven Luther wrote:
On Wed, Sep 06, 2006 at 12:11:08PM +1000, Anthony Towns wrote:
On Tue, Sep 05, 2006 at 05:54:25PM +0200, Sven Luther wrote:
We are quickly reaching the point where
[EMAIL PROTECTED] (Marco d'Itri) writes:
On Sep 06, Thomas Bushnell BSG [EMAIL PROTECTED] wrote:
No, it's a contentious issue because some people are trying hard to
change the values of Debian replacing what was a compromise widely
accepted by everybody in Debian and most people outside
On Sep 06, Thomas Bushnell BSG [EMAIL PROTECTED] wrote:
No, it's a contentious issue because some people are trying hard to
change the values of Debian replacing what was a compromise widely
accepted by everybody in Debian and most people outside Debian with
mindlessly following their
[EMAIL PROTECTED] (Marco d'Itri) writes:
The widely accepted custom was to interpret the DFSG this way, yes.
This is what matters.
What is your evidence of this?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Hi all.
We are quickly reaching the point where holding a vote on this issue and still
maintaining a timely etch release, so i believe that we should held a vote on
this issue sooner rather than later.
This GR, which was seen by Steve as orthogonal to his GR, is about the etch
release and not
Russ Allbery [EMAIL PROTECTED] writes:
Not for some reason, for some very obvious reasons. They're not adequate
as an immediate solution to this problem because separating the firmware
from the packages that currently contain it is hard and needs development
and because d-i currently can't
Marco d'Itri [EMAIL PROTECTED] writes:
No, it's a contentious issue because some people are trying hard to
change the values of Debian replacing what was a compromise widely
accepted by everybody in Debian and most people outside Debian with
mindlessly following their idea of the DFSG.
I'm
On Tue, Sep 05, 2006 at 05:54:25PM +0200, Sven Luther wrote:
We are quickly reaching the point where holding a vote on this issue and still
maintaining a timely etch release, so i believe that we should held a vote on
this issue sooner rather than later.
This GR, which was seen by Steve as
Thomas Bushnell BSG [EMAIL PROTECTED] writes:
Russ Allbery [EMAIL PROTECTED] writes:
Not for some reason, for some very obvious reasons. They're not
adequate as an immediate solution to this problem because separating
the firmware from the packages that currently contain it is hard and
Russ Allbery [EMAIL PROTECTED] writes:
Point 2.1.1 of the Debian Constitution is relevant here. Under the Debian
Constitution, you have no grounds for expecting the d-i team to work on
this on your preferred time scale. If you want to get work done that
other people have not completed as
Thomas Bushnell BSG [EMAIL PROTECTED] writes:
I am entirely happy for the d-i team to never do the work. But that
does not mean that the kernel team should therefore be allowed to go
ahead and ship non-free programs in their packages.
That's something different than what you said in your
Marco d'Itri [EMAIL PROTECTED]
Yes, I would strongly object. I am very annoyed at people who consider
some GPL'ed drivers to be contrib material because the hardware they
support stores its proprietary firmware on the system hard disk instead
of on a flash eeprom chip like some other hardware.
Marco d'Itri [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] wrote:
The only compromise I can see is a new archive section different from
main, contrib or non-free which will be considered part of Debian and
distributed on our CD and netboot images.
Like, say, 'restricted'?
--
[EMAIL PROTECTED] wrote:
Not for some reason, for some very obvious reasons. They're not adequate
as an immediate solution to this problem because separating the firmware
from the packages that currently contain it is hard and needs development
*And* will need work from the kernel team for the
What strikes me as ironic, with these proposals, is that we ran into
something like this problem back in the 90s, back during the initial
adoption of the DFSG, and we had to solve that problem then:
we created the non-free and contrib sections.
For some reason, these sections are no longer seen
Raul Miller [EMAIL PROTECTED] writes:
What strikes me as ironic, with these proposals, is that we ran into
something like this problem back in the 90s, back during the initial
adoption of the DFSG, and we had to solve that problem then: we created
the non-free and contrib sections.
For some
On Thu, Aug 31, 2006 at 12:48:35AM -0400, Nathanael Nerode wrote:
Actually, this is what is wrong with the polls at the debian user forums
which AJ pointed people to. Etch can release on time either free (with
less hardware support) or non-free (with more hardware support).
Making Release
On Thu, Aug 31, 2006 at 12:48:35AM -0400, Nathanael Nerode wrote:
Sven Luther wrote:
Yeah, that is something which is needed. We need someone to go over
larry's list, which i have copiedto the debian wiki, and find out who the
copyright holder of those problematic firmwares are, and then we
On Wed, Aug 30, 2006 at 10:42:12PM -0700, Thomas Bushnell BSG wrote:
Frederik Schueler [EMAIL PROTECTED] writes:
1. We affirm that our Priorities are our users and the free software
community (Social Contract #4);
2. We acknowledge that there is a lot of progress in the kernel firmware
Hi,
On Wed, 30 Aug 2006, Thomas Bushnell BSG wrote:
Further, because this amounts to a decision to disregard the SC, it
should require a 3:1 majority.
It's not disregarding the SC, it's clarifying the fact that we need more
time to create the proper infrastructure that will allow us to support
On Wed, Aug 30, 2006 at 11:06:54PM +0200, Frederik Schueler wrote:
Seconded.
Overview:
The Linux kernel source contains device drivers that ship with firmware
files provided by the hardware manufacturer. They are uploaded during
the driver initialization to the corresponding hardware
On Wed, Aug 30, 2006 at 08:47:08PM -0400, Nathanael Nerode wrote:
Frederik Schueler wrote:
So, this is an I'm OK with the actual GR but object strongly to the
overview post.
Overview:
The Linux kernel source contains device drivers that ship with firmware
files provided by the
On Thu, Aug 31, 2006 at 09:21:12AM +0200, Raphael Hertzog wrote:
Hi,
On Wed, 30 Aug 2006, Thomas Bushnell BSG wrote:
Further, because this amounts to a decision to disregard the SC, it
should require a 3:1 majority.
It's not disregarding the SC, it's clarifying the fact that we need
Qua, 2006-08-30 às 23:06 +0200, Frederik Schueler escreveu:
So, we propose this GR:
1. We affirm that our Priorities are our users and the free software
community (Social Contract #4);
2. We acknowledge that there is a lot of progress in the kernel firmware
issue; however, it is not yet
Qui, 2006-08-31 às 09:19 +0100, Daniel Ruoso escreveu:
Qua, 2006-08-30 às 23:06 +0200, Frederik Schueler escreveu:
So, we propose this GR:
1. We affirm that our Priorities are our users and the free software
community (Social Contract #4);
2. We acknowledge that there is a lot of
Le jeu 31 août 2006 09:50, Enrico Zini a écrit :
...and get Lars tatooed! :)
what an unfair way to get the vote biased for that proposal ! :)
--
·O· Pierre Habouzit
··O[EMAIL PROTECTED]
OOO
Enrico Zini writes:
On Wed, Aug 30, 2006 at 11:06:54PM +0200, Frederik Schueler wrote:
We want to emphasize that the success of this GR is considered as
necessary by the kernel and release team for successfully delivering etch
in time (and to allow us a successful planning of that).
...and
Sven Luther [EMAIL PROTECTED] writes:
It seems to me that this GR is unacceptable in this form because it
does not give an adequate definition of firmware, and people seem to
mean many different things by it.
Well, in this case, firmware is clearly the firmware blobs actually into the
Raphael Hertzog [EMAIL PROTECTED] writes:
So I don't think it's a 3:1 issue. We're not changing our goals, only
clarifying the timeline and acknowledging that the etch timeframe is too
short for us to reach this goal.
I don't believe it. We already clarified the timeline, and created a
On Thu, Aug 31, 2006 at 11:05:10AM -0700, Thomas Bushnell BSG wrote:
Sven Luther [EMAIL PROTECTED] writes:
It seems to me that this GR is unacceptable in this form because it
does not give an adequate definition of firmware, and people seem to
mean many different things by it.
Well,
Sven Luther [EMAIL PROTECTED] writes:
So how do I know whether something is firmware instead of just
ordinary sourceless code?
Ah, well, i would say that the definition you search here are :
hexdump sourceless blobs which are uploaded to a peripheral device.
So you would say that it is
On Thu, Aug 31, 2006 at 01:10:35PM -0700, Thomas Bushnell BSG wrote:
Sven Luther [EMAIL PROTECTED] writes:
So how do I know whether something is firmware instead of just
ordinary sourceless code?
Ah, well, i would say that the definition you search here are :
hexdump sourceless
Sven Luther [EMAIL PROTECTED] writes:
No. The sourceless firmware blobs mentioned in this GR, are identified as
those programs or register dumps or fpga config files, which are uploaded to a
peripheral processor, and are part of a linux kernel driver in some way,
usually an array of chars or
On Thu, Aug 31, 2006 at 02:43:59PM -0700, Thomas Bushnell BSG wrote:
Sven Luther [EMAIL PROTECTED] writes:
No. The sourceless firmware blobs mentioned in this GR, are identified as
those programs or register dumps or fpga config files, which are uploaded
to a
peripheral processor, and
Sven Luther [EMAIL PROTECTED] writes:
Nope, i am not sure we have such microcode in the kernel tree. It certainly
fits the same category as the rest of the stuff, and i think the above
identifies perfectly which firmware blobs we are speakign about.
Huh? Microcode for the main processor
On Thu, Aug 31, 2006 at 03:03:13PM -0700, Thomas Bushnell BSG wrote:
Sven Luther [EMAIL PROTECTED] writes:
Nope, i am not sure we have such microcode in the kernel tree. It certainly
fits the same category as the rest of the stuff, and i think the above
identifies perfectly which firmware
Sven Luther [EMAIL PROTECTED] writes:
Microcode for the main processor does not match (2) or (3). So no,
there is no obvious likeness between microcode for the main processor
and the rest of the stuff.
Microcode does run in a lower level of the cpu than the main code, as thus you
could see
On Thu, Aug 31, 2006 at 04:50:47PM -0700, Thomas Bushnell BSG wrote:
Sven Luther [EMAIL PROTECTED] writes:
Microcode for the main processor does not match (2) or (3). So no,
there is no obvious likeness between microcode for the main processor
and the rest of the stuff.
Microcode
On Thu, Aug 31, 2006 at 05:33:42PM -0700, Thomas Bushnell BSG wrote:
Sven Luther [EMAIL PROTECTED] writes:
Well, it would be part of a driver aimed at driving the main cpu, yes, it is
not a peripheral processor, but the role played by the microcode is
peripheral
to the main flow of the
Sven wrote -
I already did so, but let's try again :
We consider for the purpose of this GR, firmware to be :
[blah blah]
Hey, let's make it easy: let's approve shipping the same
firmware we shipped in sarge! I can list the 45 files
covered, so there's no ambiguity, no regression in hardware
Overview:
The Linux kernel source contains device drivers that ship with firmware
files provided by the hardware manufacturer. They are uploaded during
the driver initialization to the corresponding hardware device.
Some of these binary image files are provided as a hexdump of register
bank
I second the proposal cited below.
also sprach Frederik Schueler [EMAIL PROTECTED] [2006.08.30.2306 +0200]:
Overview:
The Linux kernel source contains device drivers that ship with firmware
files provided by the hardware manufacturer. They are uploaded during
the driver initialization to
Hi Frederik!
Seconded.
Bas.
You wrote:
Overview:
The Linux kernel source contains device drivers that ship with firmware
files provided by the hardware manufacturer. They are uploaded during
the driver initialization to the corresponding hardware device.
Some of these binary image
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I second the below GR proposal.
Friendly,
Sven Luther
|| Overview:
||
|| The Linux kernel source contains device drivers that ship with firmware
|| files provided by the hardware manufacturer. They are uploaded during
|| the driver
Seconded.
On Wed, Aug 30, 2006 at 11:06:54PM +0200, Frederik Schueler wrote:
Overview:
The Linux kernel source contains device drivers that ship with firmware
files provided by the hardware manufacturer. They are uploaded during
the driver initialization to the corresponding hardware
Hello,
Seconded,
Regard
Sylvain Le Gall
On Wed, Aug 30, 2006 at 11:06:54PM +0200, Frederik Schueler wrote:
Overview:
The Linux kernel source contains device drivers that ship with firmware
files provided by the hardware manufacturer. They are uploaded during
the driver initialization to
Frederik Schueler wrote:
So, this is an I'm OK with the actual GR but object strongly to the
overview post.
Overview:
The Linux kernel source contains device drivers that ship with firmware
files provided by the hardware manufacturer. They are uploaded during
the driver initialization to
On Wed, Aug 30, 2006 at 08:47:08PM -0400, Nathanael Nerode wrote:
Also, though the firmware loader allows us to put the firmware where it
belongs to (main or non-free, depending on the case), the installer can
as of now only take udebs from main. Fixing this is not too hard, but
it is
Sven Luther wrote:
On Wed, Aug 30, 2006 at 08:47:08PM -0400, Nathanael Nerode wrote:
snip
http://www.debian.org/devel/debian-installer will give you all the links
you want, but for the lazy :
svn://svn.debian.org/svn/d-i/trunk/packages/anna
Thank you very much.
Oddly, finding the d-i repo
Frederik Schueler [EMAIL PROTECTED] writes:
1. We affirm that our Priorities are our users and the free software
community (Social Contract #4);
2. We acknowledge that there is a lot of progress in the kernel firmware
issue; however, it is not yet finally sorted out;
3. We give priority to
83 matches
Mail list logo
