Bug reports of DFSG violations are tagged ‘lenny-ignore’?
Ben Finney
Have I missed some announcement that DFSG violations don't matter for
the release of ‘lenny’?
I ask because a whole lot of bug reports of DFSG violations have been
tagged ‘lenny-ignore’ without explanation:
<URL:http://bugs.debian.org/391935>
<URL:http://bugs.debian.org/498631>
<URL:http://bugs.debian.org/494308>
<URL:http://bugs.debian.org/494010>
<URL:http://bugs.debian.org/494009>
<URL:http://bugs.debian.org/494007>
and probably others I've missed.
Should these tags be removed? I would think at least a meaningful
justification in the bug report is required if DFSG violations are to
be explicitly ignored, but perhaps I'm wrong.
--
\ “Oh, I realize it's a penny here and a penny there, but look at |
`\ me: I've worked myself up from nothing to a state of extreme |
_o__) poverty.” —Groucho Marx |
Ben Finney
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Marc 'HE' Brockschmidt
> Have I missed some announcement that DFSG violations don't matter for
> the release of ‘lenny’?
No, because they generally matter.
> I ask because a whole lot of bug reports of DFSG violations have been
> tagged ‘lenny-ignore’ without explanation:
[...]
> and probably others I've missed.
The full list of bugs tagged lenny-ignore is available here:
http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=lenny-ignore
> Should these tags be removed?
No.
> I would think at least a meaningful justification in the bug report is
> required
Well, apply common sense. In all of the bugs I recently tagged, the DFSG
violation is usually a formal problem, something that other
distributions and upstream don't consider a problem at all. While fixing
these issues is and should be a goal of Debian, it's hardly something
that can be done in the last few weeks before releasing. The drawbacks
of delaying the release indefinitely for these bugs are much greater
than releasing with these minor DFSG violations [1].
FWIW, this has also been done for past releases (see, for example,
#211765).
Marc
Footnotes:
[1] Yeah, I'm waiting to get toasted for daring to say "minor" here.
--
BOFH #290:
The CPU has shifted, and become decentralized.
Manoj Srivastava
> Ben Finney <ben+d...@benfinney.id.au> writes:
>> I would think at least a meaningful justification in the bug report is
>> required
>
> Well, apply common sense. In all of the bugs I recently tagged, the
> DFSG violation is usually a formal problem, something that other
> distributions and upstream don't consider a problem at all. While
What does "formal" mean here? And the fact that other
distributions play fast and loose with shipping non-fre stuff should
not be an excuse for Debian to start violating the foundation
documents, so whether or not Ubuintu ships non-free drivers is not
something that Debian can point to to violate the DFSG.
> fixing these issues is and should be a goal of Debian, it's hardly
> something that can be done in the last few weeks before releasing. The
> drawbacks of delaying the release indefinitely for these bugs are much
> greater than releasing with these minor DFSG violations [1].
> FWIW, this has also been done for past releases (see, for example,
> #211765).
In the past, we passed GR's to allow us to ship with known DFSG
violations: http://www.debian.org/vote/2004/vote_004
Has the current release team lowered the bar on Debian actually
trying to follow the social contract? Is releasing on schedule more
important than the SC?
manoj
--
Arithmetic: An obscure art no longer practiced in the world's developed
countries.
Manoj Srivastava <sriv...@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Robert Millan
>
> Has the current release team lowered the bar on Debian actually
> trying to follow the social contract?
Yes, they have.
Furthermore, the FTP team (which is supposed to be in charge of DFSG
enforcement) has decided to look the other way:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=497823
Btw, I'm looking for supporters for a GR to stop this gross violation of the
SC. Any DDs who read this, please let me know if you're interested.
--
Robert Millan
The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your data and not access it at all."
Josselin Mouette
> > Has the current release team lowered the bar on Debian actually
> > trying to follow the social contract?
>
> Yes, they have.
What if, instead of ranting everywhere, you actually contributed code to
fix these bugs?
I don’t recall the release team being reluctant to letting bug fixes
(especially serious ones) migrate to lenny.
--
.''`.
: :' : We are debian.org. Lower your prices, surrender your code.
`. `' We will add your hardware and software distinctiveness to
`- our own. Resistance is futile.
Robert Millan
> While fixing
> these issues is and should be a goal of Debian, it's hardly something
> that can be done in the last few weeks before releasing.
If I may make a suggestion, instead of trying to justify that Debian should
change its goals against the will of the majority of the developers, the
release team could just keep ignoring them all the same, and instead of
referring to the result as "Debian", just find another name to make SC #1
happy.
And if you find yourself in difficulty finding a name, I think "Blobbie" is
a pretty one.
--
Robert Millan
The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your data and not access it at all."
Stephen Gran
> On Mon, Oct 20, 2008 at 08:41:16AM -0500, Manoj Srivastava wrote:
> >
> > Has the current release team lowered the bar on Debian actually
> > trying to follow the social contract?
>
> Yes, they have.
>
> Furthermore, the FTP team (which is supposed to be in charge of DFSG
> enforcement) has decided to look the other way:
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=497823
I'm not sure that an unanswered email means they are condoning it. It
just means they're not talking to you.
--
-----------------------------------------------------------------
| ,''`. Stephen Gran |
| : :' : sg...@debian.org |
| `. `' Debian user, admin, and developer |
| `- http://www.debian.org |
-----------------------------------------------------------------
Robert Millan
> Le lundi 20 octobre 2008 à 16:08 +0200, Robert Millan a écrit :
> > > Has the current release team lowered the bar on Debian actually
> > > trying to follow the social contract?
> >
> > Yes, they have.
>
> What if, instead of ranting everywhere, you actually contributed code to
> fix these bugs?
I did...
> I don’t recall the release team being reluctant to letting bug fixes
> (especially serious ones) migrate to lenny.
...but you missed the point. They're not wishlist bugs. If they were, I
wouldn't care much about them.
Thomas Viehmann
Stephen Gran said:
> This one time, at band camp, Robert Millan said:
> > On Mon, Oct 20, 2008 at 08:41:16AM -0500, Manoj Srivastava wrote:
> > >
> > > Has the current release team lowered the bar on Debian actually
> > > trying to follow the social contract?
> >
> > Yes, they have.
> >
> > Furthermore, the FTP team (which is supposed to be in charge of DFSG
> > enforcement) has decided to look the other way:
> >
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=497823
>
> I'm not sure that an unanswered email means they are condoning it. It
> just means they're not talking to you.
... with a CC to that bug report.
I queried Robert on IRC and told him that he does not have a realistic
scenario of fixing the bug and that he would need to come up with a
working NMUable patch to in order to even have a viable proposition to
move things forward.[1]
What are the release and ftp team supposed to do here? Sure, I can
type in "dak rm linux-2.6" and see what happens except the www.d.o
pseudopackage receiving a bug about removing me from the
FTP-Assistants list. Disposing of the luggage that is each
supplementaryGid line in LDAP would enable me to move on to happier
projects more easily.[2]
As Robert himself says, these bugs have been known for four years.
They are RC, if you did not prepare an NMU should ask yourself why you
did not and stop pretending that it is the release or ftp team's
responsibility to fix the RC bugs that you are not fixing.
The options from a FTP or release point of view are exactly keep
stuff, drop stuff, replace stuff by better stuff. That better stuff
needs to be available, though, and you are as much to blame for that
as everyone else.
Kind regards
T.
1. And yes, the bug about e100 (#494308) contains an unanswered
question by Robert. But to me it reads as "Do you want a patch that
does not work or a longer one that actually works?" which without
doubt has not been answered because it is a deep philosophical
question and puzzling everyone who ever looked at that bug to the
point where they have to cease all activity on RC bugs and relax by
enjoying a decent flamewar on debian-devel.
2. Every single time I look at the RC bug list, my first thought is
about my exit strategy before I am even able to start considering
the bug at hand.
My pet flamewar would be about quality in Debian and whether the
DAM needs to designate some people as Developers who do not
maintain packages, but I can restrain myself enough to wait until
after the release.
--
Thomas Viehmann, http://thomas.viehmann.net/
Manoj Srivastava
> Btw, I'm looking for supporters for a GR to stop this gross violation
> of the SC. Any DDs who read this, please let me know if you're
> interested.
Actually, I think we need a GR on the lines of
,----
| http://www.debian.org/vote/2006/vote_007
| General Resolution: Handling source-less firmware in the Linux kernel
`----
To get a special dispensation for lenny.
If someone were to propose such a GR, I would second it. If the
DPL gives us leave to cut down discussion and voting to a week, we
could get the decision in a couple of weeks.
I do not think that willfully violating the social contract is a
decision for a few delegates to make -- we, as a project, should
acknowledge the need for and make a special exception to release Debian
with known non-free bits in it.
manoj
--
If Machiavelli were a programmer, he'd have worked for AT&T.
Manoj Srivastava <sriv...@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Josselin Mouette
> On Mon, Oct 20, 2008 at 04:21:24PM +0200, Josselin Mouette wrote:
> > What if, instead of ranting everywhere, you actually contributed code to
> > fix these bugs?
>
> I did...
And you deserve kudos for that. But that doesn’t make this current
thread less of a troll. You cannot ask, so late in the release process,
to introduce several thousand-lines patches in the kernel, even if they
finally exist. And you can’t say you were ignoring the situation until
now. It should have been obvious that, given how they evolved, these
bugs would be ignored for lenny.
> > I don’t recall the release team being reluctant to letting bug fixes
> > (especially serious ones) migrate to lenny.
>
> ...but you missed the point. They're not wishlist bugs. If they were, I
> wouldn't care much about them.
They are serious bugs. And if we waited to have zero serious bugs before
releasing, we’d never release. That’s why lenny-ignore tags are here.
Cheers,
Robert Millan
>
> What are the release and ftp team supposed to do here? Sure, I can
> type in "dak rm linux-2.6" and see what happens
Move it to non-free. Then have it go to NEW the next time it's uploaded,
and go through the usual DFSG-ness check (but this time with aid, since
you can check the BTS for known issues).
> They are RC, if you did not prepare an NMU should ask yourself why you
> did not and stop pretending that it is the release or ftp team's
> responsibility to fix the RC bugs that you are not fixing.
The maintainers pretend that the only acceptable fix is one that:
- Implements userland load (with the firmware blob added to non-free).
- Has been tested on the affected hardware.
Since I have interest in the Social Contract but not in supporting non-free
stuff, I've only been working on #494010 [1] and packaged the necessary
utility [2] that would assemble the (now free) firmware.
For the rest, if I get a *firm* [3] assertion that I may NMU to fix it, you
can count on it that I would NMU by removing all the blobs and replace the
functions that process them with stubs. Then again, the maintainers don't
want that. Not my fault.
So, everyone stop complaining that I don't do the work. I already do much
more than I am morally obligued to.
[1] with much appreciated help/advice from Ben Hutchings
[2] http://ftp-master.debian.org/new/a56_1.3-1.html btw, would be really nice
if it can be fast-tracked.
[3] that means either sanctioned by the maintainers or by the DPL
--
Robert Millan
The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your data and not access it at all."
Robert Millan
>
> You cannot ask, so late in the release process,
Some of these bugs have been known for *years*. In one of them, I even got
a reply saying something along the lines of "I was expecting this one".
Josselin Mouette
> On Mon, Oct 20, 2008 at 04:21:24PM +0200, Josselin Mouette wrote:
> > What if, instead of ranting everywhere, you actually contributed code to
> > fix these bugs?
>
> I did...
And you deserve kudos for that.
But still, it is unrealistic to ask, so late in the release process,
to introduce several thousand-lines patches in the kernel, even if they
finally exist (and AFAIK there are not patches for all these bugs).
You cannot say either that you were ignoring the situation until now. It
should have been obvious that, given how they evolved, these bugs would
be ignored for lenny. It is unfortunate, but people have focused on
fixing other kinds of bugs.
> > I don’t recall the release team being reluctant to letting bug fixes
> > (especially serious ones) migrate to lenny.
>
> ...but you missed the point. They're not wishlist bugs. If they were, I
> wouldn't care much about them.
They are serious bugs. And if we waited to have zero serious bugs before
releasing, we’d never release. That’s why lenny-ignore tags are here.
The release team is not trying to lower standards, but simply to
mitigate between the issues and obtain the best compromise.
Cheers,
Josselin Mouette
> On Mon, Oct 20, 2008 at 07:16:12PM +0200, Josselin Mouette wrote:
> >
> > You cannot ask, so late in the release process,
>
> Some of these bugs have been known for *years*. In one of them, I even got
> a reply saying something along the lines of "I was expecting this one".
Still, the release team depends on the good will of developers who spend
time fixing RC bugs. And they are not the only ones that have been
sitting for way too long.
Thomas Bushnell BSG
> On Mon, Oct 20, 2008 at 08:41:16AM -0500, Manoj Srivastava wrote:
> >
> > Has the current release team lowered the bar on Debian actually
> > trying to follow the social contract?
>
> Yes, they have.
>
> Furthermore, the FTP team (which is supposed to be in charge of DFSG
> enforcement) has decided to look the other way:
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=497823
I had understood that we had passed a GR to allow--ONCE--a past release
with these bugs not fixed, with the understanding they would be fixed
the next time. Have I missed something?
Thomas
Thomas Bushnell BSG
> Actually, I think we need a GR on the lines of
> ,----
> | http://www.debian.org/vote/2006/vote_007
> | General Resolution: Handling source-less firmware in the Linux kernel
> `----
>
> To get a special dispensation for lenny.
I think this would be insane. It smacks of the nonsense of the US
Congress extending copyright over and over again, always for a "limited
term", but such that the terms just never actually expire.
I object to a second round of this. I was ok with it once, as a
compromise, but the understanding I had then was that it was a one-time
thing, to give time to actually *fix* the problem.
The kernel team should *fix the bug* and not just sit on their hands.
We should not release until it's fixed.
But the continued dishonesty of holding out one set of principles and guarantees, while granting ourselves exceptions on every release, is not tolerable to me.
> I do not think that willfully violating the social contract is a
> decision for a few delegates to make -- we, as a project, should
> acknowledge the need for and make a special exception to release Debian
> with known non-free bits in it.
We did that once. With the understanding that we wouldn't do it
again--or at least, that was my understanding--it was proffered as a
special case, a one-time thing, because of the urgency of the case.
Moreover, at the time, there was an amendment proposed to make it "as
long as required" and it got fewer votes than the one-time thing.
Pretty clearly, we *already decided* this issue, and we need no vote.
We need the relevant maintainers to be told "your unwillingness to fix
this means we will not be able to release".
I object very strongly to the feeling that I am being held hostage by
developers who will not fix the bug, and then protest "emergency! we
must release! no delay! we'll do it next time!" and then sit on their
hands again for another go-round. The solution is to refuse to play
along, and to say, "hey, you had two years; we're just going to wait
until you fix the bug."
Thomas
Robert Millan
> On Mon, 2008-10-20 at 16:08 +0200, Robert Millan wrote:
> > On Mon, Oct 20, 2008 at 08:41:16AM -0500, Manoj Srivastava wrote:
> > >
> > > Has the current release team lowered the bar on Debian actually
> > > trying to follow the social contract?
> >
> > Yes, they have.
> >
> > Furthermore, the FTP team (which is supposed to be in charge of DFSG
> > enforcement) has decided to look the other way:
> >
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=497823
>
> I had understood that we had passed a GR to allow--ONCE--a past release
> with these bugs not fixed, with the understanding they would be fixed
> the next time. Have I missed something?
Apparently, our control structures are not reliable enough to _enforce_
what we have decided. It seems we relied primarily on the release team,
which has betrayed the goals of the project, and only count on the FTP
team as a fallback, which so far has done nothing about it.
Looks clear that we need to change something don't it?
--
Robert Millan
The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your data and not access it at all."
Mark Brown
> I object to a second round of this. I was ok with it once, as a
> compromise, but the understanding I had then was that it was a one-time
> thing, to give time to actually *fix* the problem.
Note that there is currently active upstream work to allow us to address
these issues - some of the patches are present in 2.6.27, others are
still in flight. This is a vast step forward on where we were with etch
if we do decide to go down the route of releasing with exceptions again.
> We need the relevant maintainers to be told "your unwillingness to fix
> this means we will not be able to release".
I don't think that's a particularly constructive approach to take,
especially not in a volunteer project.
--
"You grabbed my hand and we fell into it, like a daydream - or a fever."
Manoj Srivastava
> I queried Robert on IRC and told him that he does not have a realistic
> scenario of fixing the bug and that he would need to come up with a
> working NMUable patch to in order to even have a viable proposition to
> move things forward.[1]
>
> What are the release and ftp team supposed to do here? Sure, I can
> type in "dak rm linux-2.6" and see what happens except the www.d.o
> pseudopackage receiving a bug about removing me from the
> FTP-Assistants list. Disposing of the luggage that is each
> supplementaryGid line in LDAP would enable me to move on to happier
> projects more easily.[2]
Seems like there are patches stripping the kernel of these
non-free blobs. So, how much would out hardware support be degraded?
How many people are affected by these non-free drivers?
>
> As Robert himself says, these bugs have been known for four years.
> They are RC, if you did not prepare an NMU should ask yourself why you
> did not and stop pretending that it is the release or ftp team's
> responsibility to fix the RC bugs that you are not fixing.
> The options from a FTP or release point of view are exactly keep
> stuff, drop stuff, replace stuff by better stuff. That better stuff
> needs to be available, though, and you are as much to blame for that
> as everyone else.
So, drop non-free stuff, iff the GR fails.
I'll be willing to help create kernel packages for a fully free
kernel and upload it, if that is what the ftp-masters want. Been a
while since I released official kernel images, but perhaps there is
chance for a second time. After all, Lance Armstrong might be riding in
the Tour de France 2009.
manoj
--
May all your PUSHes be POPped.
Manoj Srivastava <sriv...@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Marc 'HE' Brockschmidt
> It seems we relied primarily on the release team, which has betrayed
> the goals of the project,
I do not accept to be called names because I firmly believe that
Debian's goal is to distribute the best possible free software to our
users. All of our work has no value unless people are able to use the
software we integrate, test and improve.
I believe what you want to say is "I'm willing to pick up all the work
of the release team" before you start insulting the people who invest a
lot more time into this project than you do.
Marc
Thomas Bushnell BSG
> On Mon, Oct 20, 2008 at 10:55:00AM -0700, Thomas Bushnell BSG wrote:
>
> > I object to a second round of this. I was ok with it once, as a
> > compromise, but the understanding I had then was that it was a one-time
> > thing, to give time to actually *fix* the problem.
>
> Note that there is currently active upstream work to allow us to address
> these issues - some of the patches are present in 2.6.27, others are
> still in flight. This is a vast step forward on where we were with etch
> if we do decide to go down the route of releasing with exceptions again.
I think we have no need to go "down that route". We do not have to
support the hardware at all. That is an option. The fact that the
kernel maintainers would prefer a fancier thing is not the point.
We can simply not ship support for that hardware *at all*. That's
perfectly acceptable to me--even as a user of such hardware.
A patch to fix the bug--which is the inclusion of non-free things in
main--can be quickly and easily implemented. I'm oh-so-sorry if a
fancier fix is not available--but there has been plenty of time. I'm
not willing to see another release with non-free blobs in the kernel,
especially since it is really quite trivial to remove them.
> > We need the relevant maintainers to be told "your unwillingness to fix
> > this means we will not be able to release".
>
> I don't think that's a particularly constructive approach to take,
> especially not in a volunteer project.
I think that it is singularly non-constructive to see the maintainers of
packages regard compliance with our foundational documents as wishlist
items, and the release team regard such things as anything other than
show-stoppers.
Thomas
Felipe Augusto van de Wiel (faw)
Hash: SHA1
On 20-10-2008 16:32, Manoj Srivastava wrote:
> On Mon, Oct 20 2008, Thomas Viehmann wrote:
>> I queried Robert on IRC and told him that he does not have a realistic
>> scenario of fixing the bug and that he would need to come up with a
>> working NMUable patch to in order to even have a viable proposition to
>> move things forward.[1]
>>
>> What are the release and ftp team supposed to do here? Sure, I can
>> type in "dak rm linux-2.6" and see what happens except the www.d.o
>> pseudopackage receiving a bug about removing me from the
>> FTP-Assistants list. Disposing of the luggage that is each
>> supplementaryGid line in LDAP would enable me to move on to happier
>> projects more easily.[2]
>
> Seems like there are patches stripping the kernel of these
> non-free blobs. So, how much would out hardware support be degraded?
> How many people are affected by these non-free drivers?
Just as a reference, #484365 talks about linux-libre which
seems to be an effort from FSFLA to remove non-free blobs from
Linux kernel.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=484365
Kind regards,
- --
Felipe Augusto van de Wiel (faw)
"Debian. Freedom to code. Code to freedom!"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkj8268ACgkQCjAO0JDlykaAlwCfZwpQ+Rx5Pe4/rloACozBvPnw
iIoAn22gly6EjMsx97BzRWOH0ZIjQwua
=zH0D
-----END PGP SIGNATURE-----
Adeodato Simó
> Has the current release team lowered the bar on Debian actually
> trying to follow the social contract? Is releasing on schedule more
> important than the SC?
When I do my release work, I have certain tools, and decisions about how
to use them. One of these tools is britney, and another is the possibility
of saying that certain bugs will not stop the release from happening.
Every developer has tools, and decisions as well. For example, every
developer can make uploads, and they have the power to decide to upload
a VCS snapshot of a package to unstable.
For me, believe it or not, it's very important not to betray the rest of
developers with the actions I take in my role as a release person. Which
is *not* to say I won't take any actions that makes feel one particular
developer betrayed. But I do try to listen to what people have to say
about how we release, I really do.
In the case at hand, I can clearly see some people feel betrayed, and
they're in the right to be so (though IMHO they're not in their right to
speak for the developers at larege). However, and until proven wrong,
I'm convinced the majority of developers don't feel betrayed by these
"lenny-ignore" tags. I'm open to being proven wrong, though.
(If you must know, I also /personally/ believe that it's the task of
those who feel betrayed to prove the release team wrong, and not the
opposite. In my view, the release takes what is in unstable and tries to
make something coherent of it. If you are outraged with what's in
unstable, take it up with the people responsible for it. We just stamp a
number in certain versions of packages, nothing more. Unstable is also
"Debian", you know.)
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
Listening to: Dar Williams - February
Thomas Bushnell BSG
> Apparently, our control structures are not reliable enough to _enforce_
> what we have decided. It seems we relied primarily on the release team,
> which has betrayed the goals of the project, and only count on the FTP
> team as a fallback, which so far has done nothing about it.
>
> Looks clear that we need to change something don't it?
Yes, we need a rule that we never release with non-free software.
I thought we already had such a rule, but if the release team needs us
to vote on the social contract again, we can do so.
Thomas
Robert Millan
Sorry for my blunt description of the situation. Sometimes it has to come
this way, but I don't think it's insulting.
If that makes you feel better, I dearly appreciate most of your work (that is,
the part that doesn't involve dismissing DFSG violations as non-RC issues).
Adeodato Simó
> (If you must know, I also /personally/ believe that it's the task of
> those who feel betrayed to prove the release team wrong, and not the
> opposite.
(If the release team fail to realize by themselves, I mean, should that
happen.)
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
Listening to: Dar Williams - This Was Pompeii
Manoj Srivastava
> I do not accept to be called names because I firmly believe that
> Debian's goal is to distribute the best possible free software to our
I do not think anyone has any problems with us distributing
*free* software. It is the non-free parts in main people have an issue
with.
> users.
manoj
--
The most popular labor-saving device today is still a husband with
money. Joey Adams, "Cindy and I"
Manoj Srivastava <sriv...@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Neil McGovern
> On Mon, Oct 20, 2008 at 08:48:50AM +0200, Marc 'HE' Brockschmidt wrote:
> > While fixing
> > these issues is and should be a goal of Debian, it's hardly something
> > that can be done in the last few weeks before releasing.
>
> If I may make a suggestion, instead of trying to justify that Debian should
> change its goals against the will of the majority of the developers,
Not the majority, try again (hint: 271 < ~500).
> the release team could just keep ignoring them all the same, and
> instead of referring to the result as "Debian", just find another name
> to make SC #1 happy.
Debian vote is -> way. I'll be happy to take a GR vote off you.
> And if you find yourself in difficulty finding a name, I think "Blobbie" is
> a pretty one.
>
We've got plenty, thanks. If you want to enforce your own name, perhaps
helping with the release may be a path to becoming a RM yourself.
Neil
--
<moray> hm, maybe wearing a black t-shirt while dusting my bedroom for the
first time in years wasn't such a good idea
Neil McGovern
> On Mon, Oct 20, 2008 at 08:46:18PM +0200, Marc 'HE' Brockschmidt wrote:
> > Robert Millan <r...@aybabtu.com> writes:
> > > It seems we relied primarily on the release team, which has betrayed
> > > the goals of the project,
> >
> > I do not accept to be called names because I firmly believe that
> > Debian's goal is to distribute the best possible free software to our
> > users. All of our work has no value unless people are able to use the
> > software we integrate, test and improve.
> >
> > I believe what you want to say is "I'm willing to pick up all the work
> > of the release team" before you start insulting the people who invest a
> > lot more time into this project than you do.
>
> Sorry for my blunt description of the situation. Sometimes it has to come
> this way, but I don't think it's insulting.
>
It is incredibly insulting.
> If that makes you feel better, I dearly appreciate most of your work (that is,
> the part that doesn't involve dismissing DFSG violations as non-RC issues).
>
Not at all. A justification that involves a 'but' is nullified. If you
really want to help, I'd love to see some drivers that you consider free
that will replace the ones that you don't.
Neil
--
* hermanr feels like a hedgehog having sex...
Robert Millan
> On Mon, 2008-10-20 at 20:18 +0200, Robert Millan wrote:
> > Apparently, our control structures are not reliable enough to _enforce_
> > what we have decided. It seems we relied primarily on the release team,
> > which has betrayed the goals of the project, and only count on the FTP
> > team as a fallback, which so far has done nothing about it.
> >
> > Looks clear that we need to change something don't it?
>
> Yes, we need a rule that we never release with non-free software.
>
> I thought we already had such a rule, but if the release team needs us
> to vote on the social contract again, we can do so.
We already have a stronger rule in SC, saying that Debian (including
unreleased versions) is 100% free.
Obviously, there's always going to be a time lapse between the moment in
which a bug is filed and a fix is uploaded. We used to think the upper limit
to that lapse would be "till next release", but one can't rely on the release
team to enforce that anymore, so why not define an upper limit in GR instead?
I'll be working on this tomorrow and send a draft to -vote. Please participate
in the discussion if you can.
--
Robert Millan
The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your data and not access it at all."
Manoj Srivastava
> For me, believe it or not, it's very important not to betray the rest of
> developers with the actions I take in my role as a release person. Which
> is *not* to say I won't take any actions that makes feel one particular
> developer betrayed. But I do try to listen to what people have to say
> about how we release, I really do.
But developers are not the only infliences on your decision. You
have agreed to abide by the social contract, have you not? That, too,
should dictate how you act within your delegated role.
> In the case at hand, I can clearly see some people feel betrayed, and
> they're in the right to be so (though IMHO they're not in their right
> to speak for the developers at larege). However, and until proven
> wrong, I'm convinced the majority of developers don't feel betrayed by
> these "lenny-ignore" tags. I'm open to being proven wrong, though.
I have no idea about how betrayal features here: I just believe
that the decision to ignore these problems in Lenny fall beyond the
powers given to delegates.
There is nothing to feel betrayed by, all kinds of people make
all kinds of mistakes, and I do not live in a perpetual feeling of
victimization or betrayal.
> (If you must know, I also /personally/ believe that it's the task of
> those who feel betrayed to prove the release team wrong, and not the
> opposite. In my view, the release takes what is in unstable and tries to
> make something coherent of it. If you are outraged with what's in
> unstable, take it up with the people responsible for it. We just stamp a
> number in certain versions of packages, nothing more. Unstable is also
> "Debian", you know.)
In other words, if the release team is allowing packages to
violate the DFSG, one must prove something to the relese team (not sure
what that is, exactly). Is it in dispute that non-free blobs that
violate the DFSG actually violate the DFSG?
Or does the release team need someone to quote the contitution
and the social contrat to them? (I doubt that is the case, since the
RM"s are mostly quite competent)
Are you saying you want the project to show you that the SC is
still relevant, by passing yet another GR?
Please pardon my confusion, since you ought to be aware that
English is not my first (or second) language.
So, could you explain your view of the issue here, without
bringing in feeling of betrayal, which I do not comprehend?
manoj
--
"Survey says..." Richard Dawson, weenie, on "Family Feud"
Manoj Srivastava <sriv...@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Manoj Srivastava
This email is an edited excerpt from Sven Luther, sent via
private email. I am sending in a version I am happy to defend posting,
and will try to convey as much of what Sven said as I am comfortable
forwarding. I have marked where I paraphrased what Sven said.
manoj
> On Mon, Oct 20, 2008 at 10:55:00AM -0700, Thomas Bushnell BSG wrote:
>> On Mon, 2008-10-20 at 11:43 -0500, Manoj Srivastava wrote:
>> > Actually, I think we need a GR on the lines of
>> > ,----
>> > | http://www.debian.org/vote/2006/vote_007> > | General Resolution: Handling source-less firmware in the Linux kernel
>> > `----
>> > To get a special dispensation for lenny.
>> I think this would be insane. It smacks of the nonsense of the US
>> Congress extending copyright over and over again, always for a "limited
>> term", but such that the terms just never actually expire.
>> I object to a second round of this. I was ok with it once, as a
>> compromise, but the understanding I had then was that it was a one-time
>> thing, to give time to actually *fix* the problem.
>> The kernel team should *fix the bug* and not just sit on their hands.
>> We should not release until it's fixed.
>> But the continued dishonesty of holding out one set of principles and
>> guarantees, while granting ourselves exceptions on every release, is
>> not tolerable to me.
> Well, what do you expect ? When we last have this discussion, the
> actual GR which the kernel team wanted to be something we could use to
> actually work on this issue, and as a statement of fact for hardware
> manufacturers.
<paraphrase> However, the GR that was passed differed significantly from
<paraphrase> that. Because of that, and the fact that the kernel team
<paraphrase> lost members and is stretched thin, it is no wonder that
<paraphrase> nobody did take the torch up and fix the issue until now.
> Sven Luther
--
The Czechs announced after Sputnik that they, too, would launch a
satellite. Of course, it would orbit Sputnik, not Earth!
Ben Finney
> Ben Finney <ben+d...@benfinney.id.au> writes:
> > I would think at least a meaningful justification in the bug
> > report is required
>
> Well, apply common sense.
Common sense, i.e. the policy, social contract, and DFSG that are each
agreed in common by all DDs, would have those bugs prevent packages
violating the DFSG from being released in Debian.
If you have some other justification that overrides this common sense,
*please* make it explicit in the bug report when tagging bugs to be
ignored despite the evident unsuitability of the package for release.
> In all of the bugs I recently tagged, the DFSG violation is usually
> a formal problem, something that other distributions and upstream
> don't consider a problem at all.
That appears to be a no-op: other distributions and upstream have not
in general made an explicit social contract to follow the DFSG, while
the Debian project has done so.
> While fixing these issues is and should be a goal of Debian, it's
> hardly something that can be done in the last few weeks before
> releasing.
Is that release deadline externally imposed, then? Are we bound to
release on a specific date regardless of what bugs, ‘lenny-ignore’
tagged or otherwise, remain in the packages?
Or is it the case, as I'd understood from the guiding documents of the
Debian project, that it's more important to release Debian such that
it meets the project's own promises?
> The drawbacks of delaying the release indefinitely for these bugs
> are much greater than releasing with these minor DFSG violations
> [1].
This is a fallacy of the excluded middle. You omit the option to
remove the parts of the work that violate the DFSG, which is a
long-accepted solution to these types of bugs.
--
\ “Dare to be naïve.” —Richard Buckminster Fuller, personal motto |
`\ |
_o__) |
Ben Finney
Adeodato Simó
Hi,
> But developers are not the only infliences on your decision. You
> have agreed to abide by the social contract, have you not? That, too,
> should dictate how you act within your delegated role.
[...]
> There is nothing to feel betrayed by, all kinds of people make
> all kinds of mistakes, and I do not live in a perpetual feeling of
> victimization or betrayal.
[...]
> In other words, if the release team is allowing packages to
> violate the DFSG, one must prove something to the relese team (not sure
> what that is, exactly). Is it in dispute that non-free blobs that
> violate the DFSG actually violate the DFSG?
> Or does the release team need someone to quote the contitution
> and the social contrat to them? (I doubt that is the case, since the
> RM"s are mostly quite competent)
> Are you saying you want the project to show you that the SC is
> still relevant, by passing yet another GR?
> Please pardon my confusion, since you ought to be aware that
> English is not my first (or second) language.
> So, could you explain your view of the issue here, without
> bringing in feeling of betrayal, which I do not comprehend?
I agreed to abide by the social contract, but I happen to think that
these lenny-ignore tags at hand are acceptable in order to get a release
out, /and/ I also believe that a majority of the developers happens to
think the same (otherwise I wouldn't condone their use; I repeat: if I
thought most DDs would think they are not reasonable, I would not
approve of them even if they'd be reasonable to me).
I may as well be mistaken in this belief, so I'm open to being proved
wrong. To be proven, specifically, that the developers at large don't
want these lenny-ignore tags applied. (That should answer your question
above.)
> I have no idea about how betrayal features here: I just believe
> that the decision to ignore these problems in Lenny fall beyond the
> powers given to delegates.
This is a very interesting point, actually. My opinion is that: (a) they
are a tool the release team should have, (b) the release team should not
drift from the project at large in their use, (c) as with every other
decision from a developer, they are always overrideable by a GR.
HTH,
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
Listening to: Dar Williams - This Was Pompeii
Moritz Muehlenhoff
>> > > Has the current release team lowered the bar on Debian actually
>> > > trying to follow the social contract?
>> >
>>
>> What if, instead of ranting everywhere, you actually contributed code to
>> fix these bugs?
>
> I did...
You contributed one(!) - untested - patch for e100 and did nothing for the
rest since beginning of August.
These bugs were tagged "help" by the Debian Kernel Team since the same
day you filed them. The same team, which is already heavily overworked
and which already fixed/pruned lots of drivers with the 2.6.23-1 upload.
If it were really important, why didn't you start with this directly after
Etch release? Why didn't you do anything substantially since two and a half
months?
Where are your patches working on these issues upstream? If it is so
important to you, why didn't you even notice that all this firmware
separation work is already going on upstream led by David Woodhouse?
(The same applies to Nathanael Nerode, who never did a thing to get
all this resolved instead of pestering around)
> ...but you missed the point. They're not wishlist bugs. If they were, I
> wouldn't care much about them.
Well, bugs don't get magically fixed.
You didn't do anything substantially about them, so you can hardly complain.
Cheers,
Moritz
Mark Brown
No, really. The kernel team are volunteers. Ordering them to do things
doesn't help at all; one could equally well send the same message to
everyone working on Debian (or, indeed, the wider community) since they
could also step up to the plate and help fix this issue.
If they were actively stopping people working on these issues then that
would be different but I have not seen them doing this.
--
"You grabbed my hand and we fell into it, like a daydream - or a fever."
Felipe Augusto van de Wiel (faw)
Hash: SHA1
On 20-10-2008 19:09, Adeodato Simó wrote:
> * Manoj Srivastava [Mon, 20 Oct 2008 15:14:15 -0500]:
[...]
>> So, could you explain your view of the issue here, without
>> bringing in feeling of betrayal, which I do not comprehend?
>
> I agreed to abide by the social contract, but I happen to think that
> these lenny-ignore tags at hand are acceptable in order to get a release
> out, /and/ I also believe that a majority of the developers happens to
> think the same (otherwise I wouldn't condone their use; I repeat: if I
> thought most DDs would think they are not reasonable, I would not
> approve of them even if they'd be reasonable to me).
>
> I may as well be mistaken in this belief, so I'm open to being proved
> wrong. To be proven, specifically, that the developers at large don't
> want these lenny-ignore tags applied. (That should answer your question
> above.)
This sounds like "appeal to popularity", just because
a supposed majority do not care about something being applied
that doesn't instantly make it reasonable.
I do accept that lenny-ignore tags are an important
tool for the Release Team to make another successful release,
but I also think we will need to handle the non-free linux
blobs in some way.
People may had been harsh in expressing their feelings
about the situation, now that the problem got a lot more
attention, my honest question is: what are the alternatives we
have from the Kernel and Release Team point of views? I mean,
do we have other alternatives besides doing something similar
we did for etch?
Kind regards,
- --
Felipe Augusto van de Wiel (faw)
"Debian. Freedom to code. Code to freedom!"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkj8/eYACgkQCjAO0JDlykaAKACff3Lkfb9CsMHWDdGNeQCo5T9X
bK8AoNJZp81/YQW5oiUZJ5M407PpVQb1
=fX56
-----END PGP SIGNATURE-----
Franklin PIAT
> On Mon, 2008-10-20 at 11:43 -0500, Manoj Srivastava wrote:
> > Actually, I think we need a GR on the lines of
> > ,----
> > | http://www.debian.org/vote/2006/vote_007
> > | General Resolution: Handling source-less firmware in the Linux kernel
> > `----
> >
> > To get a special dispensation for lenny.
>
> I think this would be insane. It smacks of the nonsense of the US
> Congress extending copyright over and over again, always for a "limited
> term", but such that the terms just never actually expire.
According to [1], we are talking about 13 bugs.
5 were opened in August
2 were opened in September
7 were opened in October
Thanks to those who hunted those bugs (Robert and Ben), and those who
submitted patches (Robert and Ben).
> I object very strongly to the feeling that I am being held hostage by
> developers who will not fix the bug, and then protest "emergency! we
> must release! no delay! we'll do it next time!" and then sit on their
> hands again for another go-round. The solution is to refuse to play
> along, and to say, "hey, you had two years; we're just going to wait
> until you fix the bug."
None of the "ignore-lenny" bugs have been opened for two years, right ?
How can we expect magazines to reserve their cover-page for us, if they
have no clue about when we release ?
I'm not saying it's fine to violate SC, I'm just the kind of guy who
accept some compromises (temporary compromises here).
May be we should only allow such "ignore-lenny" violation, if N+1 (i.e
2.6.27) has the guilty feature removed in experimental?
BTW, Kudos to the D-I team who did an excellent job handling non-free
firmware in Lenny. A user is prompted for non-free firmware. That's a
very good way to reverse the "not supported" paradigm: As far as a user
is concerned, it is not Linux that doesn't support "my" device, it is
"my" device that require a damned non-free driver.
Franklin
[1] http://bugs.debian.org/cgi-bin/pkgreport.cgi?include=subject%3Afirmware;tag=lenny-ignore
Manoj Srivastava
> I agreed to abide by the social contract, but I happen to think that
> these lenny-ignore tags at hand are acceptable in order to get a release
> out, /and/ I also believe that a majority of the developers happens to
> think the same (otherwise I wouldn't condone their use; I repeat: if I
> thought most DDs would think they are not reasonable, I would not
> approve of them even if they'd be reasonable to me).
I think that we should not just assume that the developers think
that violating the DFSG is acceptable just to release a new version. I
think we should have the project explicitly state this, via a GR, like
we have done for the last two releases.
We should not get so blase about violating the DFSG that we do
not even ask, and just assume eveyone is going to just accept DFSG
violations in a core component because it is facile, and because
somehow the release when we are ready sentiment is old fashioned.
> This is a very interesting point, actually. My opinion is that: (a) they
> are a tool the release team should have, (b) the release team should not
> drift from the project at large in their use, (c) as with every other
> decision from a developer, they are always overrideable by a GR.
The tools do not make decisions, people do. I also think that
the foundation documents codify what the core values for the project
are. If the release team is drifting away from the foundation
documents, I think they are drifting away from the project at large, by
definition.
If you want a GR to tell you you should follow the social
contract, I suppose we'll have to go through the motions.
If the social contract and the whole freedom thing have become
passe, and the project members think so, we should then pass a GR
deleting the SC and the DFSG, and just ship whatever is convenient. I
am not sure I would still want to be part of the project that does
that, though.
manoj
--
To the systems programmer, users and applications serve only to provide
a test load.
Manoj Srivastava <sriv...@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Ben Hutchings
> Le lundi 20 octobre 2008 à 16:34 +0200, Robert Millan a écrit :
> > On Mon, Oct 20, 2008 at 04:21:24PM +0200, Josselin Mouette wrote:
> > > What if, instead of ranting everywhere, you actually contributed code to
> > > fix these bugs?
> >
> > I did...
>
>
> But still, it is unrealistic to ask, so late in the release process,
> to introduce several thousand-lines patches in the kernel, even if they
> finally exist (and AFAIK there are not patches for all these bugs).
These patches exist, and they change less than a thousand lines in
total. Here's the state of things:
driver bug "source" file(s) licence action
---------------------------------------------------------------------------------
cassini 498631 net/cassini.h GPLv2 remove
dabusb 502663 media/video/dabfirmware.h BSDish move (dabusb)
dsp56k 494010 char/dsp56k.c GPLv2 add source
e100 494308 net/e100.c BSDish move (e100)
kaweth 502665 net/usb/kawethfw.h GPLv2 remove
mga 502666 char/drm/mga_ucode.h MIT move (matrox)
qla1280 502667 scsi/ql1{2160,040,280}_fw.h GPLv2 remove
r128 494007 char/drm/r128_cce.c MIT move (ati)
radeon 494009 char/drm/radeon_microcode.h MIT move (ati)
starfire 501152 net/starfire_firmware.h unmodified redist move (adaptec)
tehuti 501153 net/tehuti_fw.h GPLv2 remove
typhoon 502669 net/typhoon-firmware.h unmodified redist move (3com)
whiteheat 502668 usb/serial/whiteheat_fw.h GPLv2 remove
"Action" is what my changes would do. If the licence requires source
distribution, remove. If the licence allows binary-only distribution,
move to firmware-nonfree (the names given are the package names minus
the leading "firmware-". In the case of dsp56k we can provide the
source. In fact Robert has been working to provide a package of the
assembler for the source.
The modified linux-2.6 and firmware-nonfree source packages, and the
linux-source-2.6.26 and firmware-* binary packages, can be found in:
http://people.debian.org/~benh/firmware-removal/
Please test them if you can. I have only been able to test the radeon
changes myself.
Ben.
PS: I've now managed to find firmware for qla1280
<http://www.openbsd.org/cgi-bin/cvsweb/src/sys/dev/microcode/isp/>,
tehuti
<http://www.openbsd.org/cgi-bin/cvsweb/src/sys/dev/microcode/tht/> and
kaweth <http://people.freebsd.org/~wpaul/KLSI/4.0/kue_fw.h> under a
4-clause BSD licence, so they are candidates for firmware-nonfree after
all. The BSD driver for Cassini doesn't have the Saturn firmware patch
and there seems to be no BSD driver for Whiteheat.
Thomas Bushnell BSG
> No, really. The kernel team are volunteers. Ordering them to do things
> doesn't help at all; one could equally well send the same message to
> everyone working on Debian (or, indeed, the wider community) since they
> could also step up to the plate and help fix this issue.
Of course. These are RC bugs. I would be happy to upload an NMU that
fixed the RC issue by removing support for the relevant hardware, and
dropping blobs from the source. I don't think it's a very challenging
task, but I'm happy to do so. Will that be ok?
> If they were actively stopping people working on these issues then that
> would be different but I have not seen them doing this.
Great, so since there won't be any active attempts to stop, I can just
go ahead with the work, right?
Thomas
Ben Finney
> Well, bugs don't get magically fixed.
> You didn't do anything substantially about them, so you can hardly
> complain.
These specific bug reports describe instances where the Debian project
breaks its own promises, which is why their severity is ‘serious’. The
complaint is that positive action is being taken (the tagging of bug
reports so that they are to be ignored for a Debian release) to ensure
that breach occurs.
Every recipient of the social contract's promise is entitled to hold
the Debian project to its promises.
--
\ “No matter how cynical you become, it's never enough to keep |
`\ up.” —Jane Wagner, via Lily Tomlin |
_o__) |
Ben Finney
Ben Hutchings
> On Mon, Oct 20, 2008 at 12:22:25PM -0700, Thomas Bushnell BSG wrote:
> > On Mon, 2008-10-20 at 19:11 +0100, Mark Brown wrote:
> > > On Mon, Oct 20, 2008 at 10:55:00AM -0700, Thomas Bushnell BSG wrote:
>
> > > > We need the relevant maintainers to be told "your unwillingness to fix
> > > > this means we will not be able to release".
>
> > > I don't think that's a particularly constructive approach to take,
> > > especially not in a volunteer project.
>
> > I think that it is singularly non-constructive to see the maintainers of
> > packages regard compliance with our foundational documents as wishlist
> > items, and the release team regard such things as anything other than
> > show-stoppers.
>
> No, really. The kernel team are volunteers. Ordering them to do things
> doesn't help at all; one could equally well send the same message to
> everyone working on Debian (or, indeed, the wider community) since they
> could also step up to the plate and help fix this issue.
Actually, I've done the last part of the work to remove firmware (mostly
adapting patches written by others). The remaining problems are (a) a
very few drivers don't have redistributable firmware (b) most of the
other patches have not been properly tested, at least not with the
Debian kernel.
Ben.
Stefano Zacchiroli
> When I do my release work, I have certain tools, and decisions about how
> to use them. One of these tools is britney, and another is the possibility
> of saying that certain bugs will not stop the release from happening.
> Unstable is also "Debian", you know.)
I found these arguments actually really convincing. So, to the GR
proposers, beware of how do you propose it, because I would have
really hard time understanding a GR that simply asks for not
*releasing* stuff which we continue *distributing* in some of our
suites (i.e., unstable). Why should the treatment be different?
... and if it is *not* different, why should be the release managers
be considered responsible for it? They "just" decide (and kudos for
all their hard work, BTW) if something which is already in Debian gets
released or not.
Cheers.
PS Note that I don't want yet to take part in judging the severity of
the issues, mostly because I'm still offline and I want to read the
bug logs. But I believe the points I've raised above are valid no
matter what is written in that bug logs.
--
Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è sempre /oo\ All one has to do is hit the right
uno zaino -- A.Bergonzoni \__/ keys at the right time -- J.S.Bach
Stefano Zacchiroli
> I think that we should not just assume that the developers think
> that violating the DFSG is acceptable just to release a new version. I
Sure, but we shouldn't assume the contrary either, and it seems to me
that a lot of participants in this thread did precisely that.
> The tools do not make decisions, people do. I also think that
> the foundation documents codify what the core values for the project
> are. If the release team is drifting away from the foundation
> documents, I think they are drifting away from the project at large, by
> definition.
But why nobody is making these very same arguments to the maintainer
of their packages or to the FTP masters FWIW? According to these
arguments they are drifting as away as the RMs. Either this is
actually so (which I don't believe), or as Dato said the general
feeling about these issues agrees with them RMs.
> If the social contract and the whole freedom thing have become
> passe, and the project members think so, we should then pass a GR
> deleting the SC and the DFSG, and just ship whatever is convenient. I
> am not sure I would still want to be part of the project that does
> that, though.
Please, don't get epic.
Truth is that this is yet another case where I would like to see more
a poll (still authenticated with devotee) to feel the general feelings
of DDs, more than a GR with a decision which would actually be a
pretest just to understand the general feeling.
Maybe Jeroen which did that in the past can fire up a poll on the fly?
The question would be as simple as: «do you agree with RMs about
tagging lenny-ignore bugs LIST_OF_BUGS_WITH_URLS?».
I'm quite sure the answer would be «yes», but here I'm entering myself
the guesswork terrain which permeates this thread.
Cheers.
Ben Finney
> On Mon, Oct 20, 2008 at 04:52:40PM -0500, Manoj Srivastava wrote:
> > I think that we should not just assume that the developers
> > think that violating the DFSG is acceptable just to release a new
> > version.
>
> Sure, but we shouldn't assume the contrary either
What, in your view, would allow such an assumption? I'd have thought
an explicit agreement to follow the social contract would be *exactly*
what's required to allow assumption that the agreement will be
followed.
> I'm quite sure the answer would be «yes», but here I'm entering
> myself the guesswork terrain which permeates this thread.
I don't see how claims of “guesswork” can be raised for assuming
that an explicit agreement remains in place unless explicitly
nullified.
--
\ “Room service? Send up a larger room.” —Groucho Marx |
`\ |
_o__) |
Ben Finney
Manoj Srivastava
> On Mon, Oct 20, 2008 at 04:52:40PM -0500, Manoj Srivastava wrote:
>> I think that we should not just assume that the developers think
>> that violating the DFSG is acceptable just to release a new version. I
> Sure, but we shouldn't assume the contrary either, and it seems to me
> that a lot of participants in this thread did precisely that.
I am not sure who you are talking about, but I assure you I have
not. My point is that we should explicitly ask, especially if it is
about having us willfully violate the DFSG.
>> The tools do not make decisions, people do. I also think that
>> the foundation documents codify what the core values for the project
>> are. If the release team is drifting away from the foundation
>> documents, I think they are drifting away from the project at large, by
>> definition.
>
> But why nobody is making these very same arguments to the maintainer
> of their packages or to the FTP masters FWIW?
They have been made to the maintainers, and my understanding is
the same arguments have been made to the ftp masters.
> According to these arguments they are drifting as away as the
> RMs. Either this is actually so (which I don't believe), or as Dato
> said the general feeling about these issues agrees with them RMs.
This does not logically follow. If the delegates are all vested
into releasing regularly on schedule, it does not mean that the project
as a wh9ole either agrees, or disagrees. Which is why we must ask.
> Truth is that this is yet another case where I would like to see more
> a poll (still authenticated with devotee) to feel the general feelings
> of DDs, more than a GR with a decision which would actually be a
> pretest just to understand the general feeling.
A straw poll would not be something which I would consider
authoritative, or binding, in any fashion, no.
manoj
--
Truthful, adj.: Dumb and illiterate. Ambrose Bierce, "The Devil's
Dictionary"
Manoj Srivastava
> On Mon, Oct 20, 2008 at 09:38:00PM +0200, Adeodato Simó wrote:
>> When I do my release work, I have certain tools, and decisions about how
>> to use them. One of these tools is britney, and another is the possibility
>> of saying that certain bugs will not stop the release from happening.
> <snip>
>> Unstable is also "Debian", you know.)
>
> I found these arguments actually really convincing. So, to the GR
> proposers, beware of how do you propose it, because I would have
> really hard time understanding a GR that simply asks for not
> *releasing* stuff which we continue *distributing* in some of our
> suites (i.e., unstable). Why should the treatment be different?
It should not. Which is why the patches proposed on -kernel
should be applied (NMU's are certainly feasible)
> ... and if it is *not* different, why should be the release managers
> be considered responsible for it? They "just" decide (and kudos for
> all their hard work, BTW) if something which is already in Debian gets
> released or not.
I am not sure that violating a foundation document falls under
the powers of a delegate. I wish it did, being a delegate, but it does
not. I looked.
manoj
--
Amnesia used to be my favorite word, but then I forgot it.
Manoj Srivastava <sriv...@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Luk Claes
> On Mon, Oct 20 2008, Stefano Zacchiroli wrote:
>
>> On Mon, Oct 20, 2008 at 09:38:00PM +0200, Adeodato Simó wrote:
>> ... and if it is *not* different, why should be the release managers
>> be considered responsible for it? They "just" decide (and kudos for
>> all their hard work, BTW) if something which is already in Debian gets
>> released or not.
>
> I am not sure that violating a foundation document falls under
> the powers of a delegate. I wish it did, being a delegate, but it does
> not. I looked.
Stop this nonsense, it's not the release team that is violating a
foundation document. It's Debian as a whole and it's happening now, not
when we release or not. The only thing we did as a release team is to
make clear that we don't want to delay the release if these bugs won't
get fixed. As always we don't object that lenny-ignore bugs would get
fixed before lenny.
Cheers
Luk
Manoj Srivastava
> Manoj Srivastava wrote:
>> On Mon, Oct 20 2008, Stefano Zacchiroli wrote:
>>
>>> On Mon, Oct 20, 2008 at 09:38:00PM +0200, Adeodato Simó wrote:
>
>>> ... and if it is *not* different, why should be the release managers
>>> be considered responsible for it? They "just" decide (and kudos for
>>> all their hard work, BTW) if something which is already in Debian gets
>>> released or not.
>>
>> I am not sure that violating a foundation document falls under
>> the powers of a delegate. I wish it did, being a delegate, but it does
>> not. I looked.
>
> Stop this nonsense, it's not the release team that is violating a
> foundation document. It's Debian as a whole and it's happening now, not
> when we release or not. The only thing we did as a release team is to
> make clear that we don't want to delay the release if these bugs won't
> get fixed. As always we don't object that lenny-ignore bugs would get
> fixed before lenny.
Hmm. I am not so sire it is nonsense. Yes, the release team is
not alone in this, and, really, all of us are somewhat to blame for not
helping the kernel team fix the DFSG violations. But I don't think that
the release team is blameless, either, since they decided to release
with DFSG violating code.
Now, if we are all so very eager to have these bugs go away, we
have no objections to an NMU with the patches that have been posted on
-kernel mailing list, right? (Note: some of these patches have only
recently been posted, so NMU's based on these patches have only just
becme possible).
manoj
--
BE ALERT!!!! (The world needs more lerts...)
Manoj Srivastava <sriv...@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Luk Claes
> On Tue, Oct 21 2008, Luk Claes wrote:
>
>> Manoj Srivastava wrote:
>>> On Mon, Oct 20 2008, Stefano Zacchiroli wrote:
>>>
>>>> On Mon, Oct 20, 2008 at 09:38:00PM +0200, Adeodato Simó wrote:
>>>> ... and if it is *not* different, why should be the release managers
>>>> be considered responsible for it? They "just" decide (and kudos for
>>>> all their hard work, BTW) if something which is already in Debian gets
>>>> released or not.
>>> I am not sure that violating a foundation document falls under
>>> the powers of a delegate. I wish it did, being a delegate, but it does
>>> not. I looked.
>> Stop this nonsense, it's not the release team that is violating a
>> foundation document. It's Debian as a whole and it's happening now, not
>> when we release or not. The only thing we did as a release team is to
>> make clear that we don't want to delay the release if these bugs won't
>> get fixed. As always we don't object that lenny-ignore bugs would get
>> fixed before lenny.
>
> Hmm. I am not so sire it is nonsense. Yes, the release team is
> not alone in this, and, really, all of us are somewhat to blame for not
> helping the kernel team fix the DFSG violations. But I don't think that
> the release team is blameless, either, since they decided to release
> with DFSG violating code.
We didn't decide to release yet...
> Now, if we are all so very eager to have these bugs go away, we
> have no objections to an NMU with the patches that have been posted on
> -kernel mailing list, right? (Note: some of these patches have only
> recently been posted, so NMU's based on these patches have only just
> becme possible).
Not in principle, though I would object an NMU that is not tested properly.
Cheers
Luk
Ben Finney
> it's not the release team that is violating a foundation document.
> It's Debian as a whole and it's happening now, not when we release
> or not.
This is an important distinction, thank you.
> The only thing we did as a release team is to make clear that we
> don't want to delay the release if these bugs won't get fixed.
Surely the requirement is not to *ignore* a serious bug, but to
*remove* the offending package unless the bug is resolved?
Yes, I understand we're talking about, in some cases, kernel packages
that have these bugs. What I don't see is why these serious bugs, that
(as you point out) violate the Debian project's foundation documents,
can be ignored for the sake of releasing on a particular date.
--
\ “I doubt, therefore I might be.” —anonymous |
`\ |
_o__) |
Ben Finney
Manoj Srivastava
> We didn't decide to release yet...
Fair enough.
>> Now, if we are all so very eager to have these bugs go away, we
>> have no objections to an NMU with the patches that have been posted on
>> -kernel mailing list, right? (Note: some of these patches have only
>> recently been posted, so NMU's based on these patches have only just
>> becme possible).
>
> Not in principle, though I would object an NMU that is not tested
> properly.
What would you call proper testing? I promise to build the kernel
images on two architectures I have access to (i386 and amd64), and test
the images on the limited set of machines I have (3). If the NMU is
uploaded to people.d.o, perhaps people with access to other hardware
can test it (though I am no, perhaps, the best candidate to create the
NMU, since Ben Hutchings has really been doing some heavy lifting with
the patches).
If an NMU of the kernel package is acceptable, in absence of the
kernel-team themselves accepting the patches and doing an MU, then
perhaps the issue has been overblown.
My impression had been that the kernel image packages were
deemed too important to NMU, especially given their impact on the
installer. I'd be happy to be proved wrong.
manoj
--
What the large print giveth, the small print taketh away.
Manoj Srivastava <sriv...@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Ben Finney
> Manoj Srivastava wrote:
> > Hmm. I am not so sire it is nonsense. Yes, the release
> > team is not alone in this, and, really, all of us are somewhat to
> > blame for not helping the kernel team fix the DFSG violations.
> > But I don't think that the release team is blameless, either,
> > since they decided to release with DFSG violating code.
>
> We didn't decide to release yet...
That's not the point being made: As I understand Manoj's point, it is
that tagging a bug ‘lenny-ignore’ is an active decision that a
particular bug, even if it represents a DFSG violation, will not be
considered in the decision to release.
To that extent, it *is* making the decision that it is acceptable to
release Debian with DFSG-violating works, in advance of the decision
to actually release.
--
\ “As the evening sky faded from a salmon color to a sort of |
`\ flint gray, I thought back to the salmon I caught that morning, |
_o__) and how gray he was, and how I named him Flint.” —Jack Handey |
Ben Finney
Marc Haber
<t...@becket.net> wrote:
>On Mon, 2008-10-20 at 22:26 +0100, Mark Brown wrote:
>> No, really. The kernel team are volunteers. Ordering them to do things
>> doesn't help at all; one could equally well send the same message to
>> everyone working on Debian (or, indeed, the wider community) since they
>> could also step up to the plate and help fix this issue.
>
>Of course. These are RC bugs. I would be happy to upload an NMU that
>fixed the RC issue by removing support for the relevant hardware, and
>dropping blobs from the source. I don't think it's a very challenging
>task, but I'm happy to do so. Will that be ok?
You're not seriously thinking that a release without E100 support does
make any sense and is any good for Debian, right?
Greetings
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Teemu Likonen
> That's not the point being made: As I understand Manoj's point, it is
> that tagging a bug ‘lenny-ignore’ is an active decision that a
> particular bug, even if it represents a DFSG violation, will not be
> considered in the decision to release.
>
> To that extent, it *is* making the decision that it is acceptable to
> release Debian with DFSG-violating works, in advance of the decision
> to actually release.
OK guys, please. As a random Debian user may I suggest that you stop
investigating _who_ is violating DFSG and instead focus on _what_ things
are the cause of violating DFSG. I guess we know about the "what" part
already and that part exists in Sid too. So I think you should do
apt-get source linux-2.6
and go fix the issues you are concerned about - or help testing the
fixes provided by others (I might do some testing too). And perhaps the
users whose hardware won't be supported anymore appreciate some help on
how to work around their problem. (It looks like this includes me.)
Anyway, thanks for all the DDs and Debian community for this
mostly-pretty-good operating system.
Aurelien Jarno
> Howdy all,
>
> Have I missed some announcement that DFSG violations don't matter for
> the release of ‘lenny’?
>
> I ask because a whole lot of bug reports of DFSG violations have been
> tagged ‘lenny-ignore’ without explanation:
>
> <URL:http://bugs.debian.org/391935>
> <URL:http://bugs.debian.org/498631>
> <URL:http://bugs.debian.org/494308>
> <URL:http://bugs.debian.org/494010>
> <URL:http://bugs.debian.org/494009>
> <URL:http://bugs.debian.org/494007>
>
> and probably others I've missed.
>
> Should these tags be removed? I would think at least a meaningful
> justification in the bug report is required if DFSG violations are to
> be explicitly ignored, but perhaps I'm wrong.
>
As it seems there are a few persons interested by getting those bugs
fixed asap, could we create a team of persons willing to deal with users
who will get affected by the removal of non-free code? I really don't
want to deal with user complaints. The best would be to use a
pseudo-package in the BTS for that, so that we can reassign bugs easily.
Then I will remove the non-free code with my packages.
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' aur...@debian.org | aure...@aurel32.net
`- people.debian.org/~aurel32 | www.aurel32.net
Aurelien Jarno
> On Mon, Oct 20, 2008 at 07:16:12PM +0200, Josselin Mouette wrote:
> >
> > You cannot ask, so late in the release process,
>
> Some of these bugs have been known for *years*. In one of them, I even got
> a reply saying something along the lines of "I was expecting this one".
>
Debian is violating the DFSG by using a non-DFSG license for its website
(see bug#238245). As the bug is opened for *years*, I suggest we proceed
with the removal of the website.
Any volunteer to work on that?
Paul Wise
> Debian is violating the DFSG by using a non-DFSG license for its website
> (see bug#238245). As the bug is opened for *years*, I suggest we proceed
> with the removal of the website.
Same for the wiki (see bug #385797). IIRC from debconf9, the plan is
to relicense where possible and delete where not. CC0 was the proposed
new license.
--
bye,
pabs
http://wiki.debian.org/PaulWise
Josselin Mouette
> The modified linux-2.6 and firmware-nonfree source packages, and the
> linux-source-2.6.26 and firmware-* binary packages, can be found in:
> http://people.debian.org/~benh/firmware-removal/
Thanks for the summary.
> Please test them if you can. I have only been able to test the radeon
> changes myself.
You know where to go now: users. Post to d-d-a, post to planet, search
for people with this hardware. Insist on it being critical for the
continued support of this hardware. If people show up, you’ve got the
tests the kernel team was requesting. If they don’t, that could mean
dropping support for this hardware is feasible.
--
.''`.
: :' : We are debian.org. Lower your prices, surrender your code.
`. `' We will add your hardware and software distinctiveness to
`- our own. Resistance is futile.
Mark Brown
> On Mon, 2008-10-20 at 22:26 +0100, Mark Brown wrote:
> > If they were actively stopping people working on these issues then that
> > would be different but I have not seen them doing this.
> Great, so since there won't be any active attempts to stop, I can just
> go ahead with the work, right?
Providing you work in a constructive fashion I really don't see why this
should be a problem. This would involve efforts to work with the kernel
maintainers and release team, of course, rather than working with no
coordination at all. As it turns out Ben has already been actively
working on this within Debian so I'd suggest that the most constructive
way forward would be to fill in the bits that are missing there, most of
which looked like testing.
--
"You grabbed my hand and we fell into it, like a daydream - or a fever."
Bastian Blank
> Seems like there are patches stripping the kernel of these
> non-free blobs. So, how much would out hardware support be degraded?
> How many people are affected by these non-free drivers?
The drm modules: Anything which includes an ATI or Matrox card and runs
X. The network modules: Not that much, it is mostly old hardware. We
already removed the bnx2x driver for the new Broadcom 10GE interfaces,
which in fact is a really new one.
Bastian
--
You canna change the laws of physics, Captain; I've got to have thirty minutes!
Thomas Weber
> On Mon, 20 Oct 2008 15:49:40 -0700, Thomas Bushnell BSG
> <t...@becket.net> wrote:
> >On Mon, 2008-10-20 at 22:26 +0100, Mark Brown wrote:
> >> No, really. The kernel team are volunteers. Ordering them to do things
> >> doesn't help at all; one could equally well send the same message to
> >> everyone working on Debian (or, indeed, the wider community) since they
> >> could also step up to the plate and help fix this issue.
> >
> >Of course. These are RC bugs. I would be happy to upload an NMU that
> >fixed the RC issue by removing support for the relevant hardware, and
> >dropping blobs from the source. I don't think it's a very challenging
> >task, but I'm happy to do so. Will that be ok?
>
> You're not seriously thinking that a release without E100 support does
> make any sense and is any good for Debian, right?
How long do you want to ignore the issue, then? It's software without
source, every other package gets a REJECTED in NEW for such stuff.
Thomas
Michal Čihař
Dne Tue, 21 Oct 2008 00:00:54 +0100
Ben Hutchings <b...@decadent.org.uk> napsal(a):
> The modified linux-2.6 and firmware-nonfree source packages, and the
> linux-source-2.6.26 and firmware-* binary packages, can be found in:
> http://people.debian.org/~benh/firmware-removal/
>
> Please test them if you can. I have only been able to test the radeon
> changes myself.
Please fix permissions:
You don't have permission to
access /~benh/firmware-removal/firmware-nonfree_0.13.2.dsc on this
server.
--
Michal Čihař | http://cihar.com | http://blog.cihar.com
Pierre Habouzit
> Am Dienstag, den 21.10.2008, 08:29 +0200 schrieb Marc Haber:
> > On Mon, 20 Oct 2008 15:49:40 -0700, Thomas Bushnell BSG
> > <t...@becket.net> wrote:
> > >On Mon, 2008-10-20 at 22:26 +0100, Mark Brown wrote:
> > >> No, really. The kernel team are volunteers. Ordering them to do things
> > >> doesn't help at all; one could equally well send the same message to
> > >> everyone working on Debian (or, indeed, the wider community) since they
> > >> could also step up to the plate and help fix this issue.
> > >
> > >Of course. These are RC bugs. I would be happy to upload an NMU that
> > >fixed the RC issue by removing support for the relevant hardware, and
> > >dropping blobs from the source. I don't think it's a very challenging
> > >task, but I'm happy to do so. Will that be ok?
> >
> > You're not seriously thinking that a release without E100 support does
> > make any sense and is any good for Debian, right?
>
> How long do you want to ignore the issue, then? It's software without
> source, every other package gets a REJECTED in NEW for such stuff.
If we weren't doing compromises, then:
* we would have no glibc (sunrpc code has licensing issues);
* until recently we would have no 3d (mesa had licensing issues);
* we would have no portmap/nfs/... (the same sunrpc issue as the
glibc);
* we would have no kernel (it's crippled with tiny offending blobs);
* we would have no DRI/DRM for many video cards;
* …
IOW we would barely be able to use some devices, only in the linux
console, and 1 time over 3 without any kind of network connectivity.
I don't say it's nothing we should _care_ about, but at some point:
* you don't have the source of your BIOS;
* you don't have the VHDL source of your CPU and all the chipsets of
your computer;
* I'm sure your laptop/computer has dozens of patented hardware bits,
so you're supporting patents while buying it, you should do a
pilgrimage to cleanse yourself from all that filth.
To add insult to the injury, the key to my home is patented, and I have
to go to special locksmith if I want to have a new one and so on, and
behind my door, there is a lot of Open Source. I should get rid of it,
it could be tainted, that would be bad wouldn't it ?
Firmwares are here because it's cheaper nowadays to have a chip that is
versatile and configured to a specific task. Older hardware had less
firmwares because the chips were made specifically for the board it was
in, and you had no problems with not having the source "code" of the
chip. So really, I see there is a double standard here, and a lot of
hypocrisy.
But sure, I still have 2 machines that use e100 at home (I think, maybe
only one), I will be delighted not to be able to install Debian on it,
because fuckwits have decided that less than 512 octets of firmware
(inside millions of slocs in the kernel) were not free enough.
--
·O· Pierre Habouzit
··O madc...@debian.org
OOO http://www.madism.org
Stefano Zacchiroli
> Debian is violating the DFSG by using a non-DFSG license for its website
> (see bug#238245). As the bug is opened for *years*, I suggest we proceed
> with the removal of the website.
>
> Any volunteer to work on that?
LOL, thanks for this :)
Thomas Weber
> On Tue, Oct 21, 2008 at 09:04:21AM +0000, Thomas Weber wrote:
> > Am Dienstag, den 21.10.2008, 08:29 +0200 schrieb Marc Haber:
> > > On Mon, 20 Oct 2008 15:49:40 -0700, Thomas Bushnell BSG
> > > <t...@becket.net> wrote:
> > > >On Mon, 2008-10-20 at 22:26 +0100, Mark Brown wrote:
> > > >> No, really. The kernel team are volunteers. Ordering them to do things
> > > >> doesn't help at all; one could equally well send the same message to
> > > >> everyone working on Debian (or, indeed, the wider community) since they
> > > >> could also step up to the plate and help fix this issue.
> > > >
> > > >Of course. These are RC bugs. I would be happy to upload an NMU that
> > > >fixed the RC issue by removing support for the relevant hardware, and
> > > >dropping blobs from the source. I don't think it's a very challenging
> > > >task, but I'm happy to do so. Will that be ok?
> > >
> > > You're not seriously thinking that a release without E100 support does
> > > make any sense and is any good for Debian, right?
> >
> > How long do you want to ignore the issue, then? It's software without
> > source, every other package gets a REJECTED in NEW for such stuff.
>
> If we weren't doing compromises, then:
You are missing my point. We[1] got a reject for a documentation PDF
without source. So, we contacted upstream who checked the copyright with
the company in order to release the source for the documentation. And
yes, it's work, painful, whatever and I would have preferred not having
to do it.
The kind of "compromise" above makes it close to impossible to argue in
such cases:
Upstream: "You are ignoring the issue in case X, why do you bother me
about Y? It's not even code, if you want the text, just extract it."
What do you expect me to say in such cases: "You are not the kernel."?
[1] Packages are group-maintained.
> I don't say it's nothing we should _care_ about, but at some point:
> * you don't have the source of your BIOS;
> * you don't have the VHDL source of your CPU and all the chipsets of
> your computer;
> * I'm sure your laptop/computer has dozens of patented hardware bits,
> so you're supporting patents while buying it, you should do a
> pilgrimage to cleanse yourself from all that filth.
Yes, and what of the above is in Debian's archive? Frankly, if binary
firmware is okay, just say so in the DFSG. No problem with me. But then
please be consistent and stop forbidding uploads for documents without
source, too. Because I'm unable to explain the difference between
"firmware without source" and "binary documentation without source". Can
you explain it?
> Firmwares are here because it's cheaper nowadays to have a chip that is
> versatile and configured to a specific task. Older hardware had less
> firmwares because the chips were made specifically for the board it was
> in, and you had no problems with not having the source "code" of the
> chip. So really, I see there is a double standard here, and a lot of
> hypocrisy.
See above, the same tale about double standards can be told as soon as
other packages enter the picture.
Robert Millan
> PS: I've now managed to find firmware for qla1280
> <http://www.openbsd.org/cgi-bin/cvsweb/src/sys/dev/microcode/isp/>,
> tehuti
> <http://www.openbsd.org/cgi-bin/cvsweb/src/sys/dev/microcode/tht/> and
> kaweth <http://people.freebsd.org/~wpaul/KLSI/4.0/kue_fw.h> under a
> 4-clause BSD licence, so they are candidates for firmware-nonfree after
> all. The BSD driver for Cassini doesn't have the Saturn firmware patch
> and there seems to be no BSD driver for Whiteheat.
Heh, I can't believe those come from the same people who keep this as one of
their official songs:
http://www.openbsd.org/lyrics.html#39
Our contradictions might not be so unique to Debian after all ...
--
Robert Millan
The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your data and not access it at all."
Anthony Towns
> On Mon, 2008-10-20 at 11:43 -0500, Manoj Srivastava wrote:
Interesting; Manoj's post isn't in the -vote archives on master. I wonder
why that is?
> > Actually, I think we need a GR on the lines of
> > ,----
> > | http://www.debian.org/vote/2006/vote_007
> > | General Resolution: Handling source-less firmware in the Linux kernel
> > `----
> > To get a special dispensation for lenny.
> I think this would be insane. [...]
> I object to a second round of this. I was ok with it once, [...]
Hrm, were you? Hey, we can check!
V: 12 tb Thomas Bushnell
-- http://www.debian.org/vote/2004/gr_editorial_tally.txt
(in favour of editorial amendments GR that made all non-free anything
unambiguously unsuitable for main; except maybe license texts)
V: 3457216 tb Thomas Bushnell
-- http://www.debian.org/vote/2004/gr_sarge_tally.txt
("The Debian Project resolves that it will not compromise on freedom,
and will never knowingly issue another release (excluding point
updates to stable releases) that contains anything in the main or
contrib sections which is not free software according to the DFSG.";
with the various proposed exceptions for sarge ranged between [2] and
[5], further discussion at [6], and reverting the previous GR at [7])
V: 12 tb Thomas Bushnell
-- http://www.debian.org/vote/2006/vote_004_tally.txt
("Reaffirms that programmatic works distributed in the Debian system
(IE, in main) must be 100% Free Software, regardless of whether the
work is designed to run on the CPU, a subsidiary processing unit,
or by some other form of execution."; Further Discussion won the day)
V: 231 tb Thomas Bushnell
-- http://www.debian.org/vote/2006/vote_007_tally.txt
(Options were "Release etch with DFSG problems, but no regressions
compared to sarge", exemptions for images and for firmware while
technically needed but with no specific end date, and further
discussion; the first option won the day)
Seems to me you held pretty much the same opinions then as you do now...
> The kernel team should *fix the bug* and not just sit on their hands.
You know, I haven't been paying any attention, but somehow I don't think
the kernel team have really just been sitting on their hands. It just
seems like maybe there's a third option, you know? Well, I don't and maybe
I'm mistaken, so as a show of good faith, here's a photo of me sitting
on my hands [0]. Because, hey, _someone_ must have been doing it, right?
> We should not release until it's fixed.
Why don't we embrace the principle fully, and remove all our old releases
too? That's not sarcasm -- I just don't see a reason to reject that idea,
but not also to keep compromising until there's no longer anything to
compromise with. AFAICS, the idea is to stop Debian users and developers
from kidding themselves that they've got a free OS and force them to fix
the remaining problems until they do. And if that's really a good idea,
why not commit to it?
But hey, I never saw the problem with only wanting to distribute free
/software/, and we know where that sort of thinking leads!
> Moreover, at the time, there was an amendment proposed to make it "as
> long as required" and it got fewer votes than the one-time thing.
> Pretty clearly, we *already decided* this issue, and we need no vote.
We decided there would be an exception for sarge, and another one for
etch. I don't think there's been any decision made via GR on lenny,
and even if there had been, another GR could quite reasonably overturn
it if enough people felt it was warranted.
> We need the relevant maintainers to be told "your unwillingness to fix
> this means we will not be able to release".
What good do you think that will do? Here, let me try:
Thomas: your continued inaction and unwillingness to code an acceptable
solution to this issue, in spite of being aware of the problem since
at least 2004 -- over four years ago! -- means we will continue to do
releases with non-free software.
Did it do any good? Is there something different about other maintainers
that will make that logic work better on them, than you?
> I object very strongly to the feeling that I am being held hostage by
> developers who will not fix the bug, and then protest "emergency! we
> must release! no delay! we'll do it next time!" and then sit on their
> hands again for another go-round. The solution is to refuse to play
> along, and to say, "hey, you had two years; we're just going to wait
> until you fix the bug."
"Hey, you've had four years; we're just going to keep releasing until
you fix the bug."
Hint: you're not being held hostage by anyone, seriously. You know how
you can tell? Two words: Stockholm syndrome.
Cheers,
aj, who knows what completely ignoring the lists is like, and wants a
fresh comparison of that to randomly trolling into flamewars
[0] http://azure.humbug.org.au/~aj/handsit.jpg
It's really kinda difficult to take a photo of yourself sitting
on both hands, especially when you can't be bothered going to any
effort. Which would, after all, defeat the purpose.
--
To UNSUBSCRIBE, email to debian-vo...@lists.debian.org
Thomas Bushnell BSG
> On Mon, 20 Oct 2008 15:49:40 -0700, Thomas Bushnell BSG
> <t...@becket.net> wrote:
> >On Mon, 2008-10-20 at 22:26 +0100, Mark Brown wrote:
> >> No, really. The kernel team are volunteers. Ordering them to do things
> >> doesn't help at all; one could equally well send the same message to
> >> everyone working on Debian (or, indeed, the wider community) since they
> >> could also step up to the plate and help fix this issue.
> >
> >Of course. These are RC bugs. I would be happy to upload an NMU that
> >fixed the RC issue by removing support for the relevant hardware, and
> >dropping blobs from the source. I don't think it's a very challenging
> >task, but I'm happy to do so. Will that be ok?
>
> You're not seriously thinking that a release without E100 support does
> make any sense and is any good for Debian, right?
Yes, I am thinking exactly that.
Thomas
Thomas Bushnell BSG
> Thomas: your continued inaction and unwillingness to code an acceptable
> solution to this issue, in spite of being aware of the problem since
> at least 2004 -- over four years ago! -- means we will continue to do
> releases with non-free software.
I am *happy* to code an acceptable solution, but I regard "not support
the hardware for installation" as acceptable.
I ask simply that the project's standards be *applied*, or that at the
very least, we have a resolution as we did before. And yes, I would
likely vote against it, as I did before. But in a democratic system,
people generally are well advised to accept the result of past votes
gracefully and work towards the next one. That's what I did; my vote
did not carry the day last time, and I have not objected about that
decision since. But I *do* object to the apparent new rule that the
ftpmasters and release engineers are now empowered to ignore DFSG
violations without any review by anyone else.
And now we have people saying, "hey, let's exempt firmware from the
DFSG!" again, even though we have a GR on topic which decided that, no,
firmware counts.
> "Hey, you've had four years; we're just going to keep releasing until
> you fix the bug."
>
> Hint: you're not being held hostage by anyone, seriously. You know how
> you can tell? Two words: Stockholm syndrome.
So I can upload an NMU right now that fixes the problem? That will be
ok?
Thomas
Manoj Srivastava
> On Mon, Oct 20, 2008 at 07:30:23PM +0200, Robert Millan wrote:
>> On Mon, Oct 20, 2008 at 07:16:12PM +0200, Josselin Mouette wrote:
>> >
>> > You cannot ask, so late in the release process,
>>
>> Some of these bugs have been known for *years*. In one of them, I even got
>> a reply saying something along the lines of "I was expecting this one".
>>
>
> Debian is violating the DFSG by using a non-DFSG license for its
> website (see bug#238245). As the bug is opened for *years*, I suggest
> we proceed with the removal of the website.
Yes, this is another thing we need to fix.
> Any volunteer to work on that?
First things first: Where do I record the fact that any
contribution I have made to the web site or the wiki may be licensed
under the GPL?
manoj
--
Ship it.
Manoj Srivastava <sriv...@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Manoj Srivastava
> On Mon, Oct 20, 2008 at 04:12:25PM +1100, Ben Finney wrote:
>> Howdy all,
>>
>> Have I missed some announcement that DFSG violations don't matter for
>> the release of ‘lenny’?
>>
>> I ask because a whole lot of bug reports of DFSG violations have been
>> tagged ‘lenny-ignore’ without explanation:
>>
>> <URL:http://bugs.debian.org/391935>> <URL:http://bugs.debian.org/498631>> <URL:http://bugs.debian.org/494308>> <URL:http://bugs.debian.org/494010>> <URL:http://bugs.debian.org/494009>> <URL:http://bugs.debian.org/494007>>
>> and probably others I've missed.
>>
>> Should these tags be removed? I would think at least a meaningful
>> justification in the bug report is required if DFSG violations are to
>> be explicitly ignored, but perhaps I'm wrong.
>>
>
> As it seems there are a few persons interested by getting those bugs
> fixed asap, could we create a team of persons willing to deal with users
> who will get affected by the removal of non-free code? I really don't
> want to deal with user complaints. The best would be to use a
> pseudo-package in the BTS for that, so that we can reassign bugs easily.
>
> Then I will remove the non-free code with my packages.
I'll sign up to be on the maintainers list for such a package.
manoj
--
Madison's Inquiry: If you have to travel on the Titanic, why not go
first class?
Manoj Srivastava <sriv...@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Manoj Srivastava
> On Mon, Oct 20, 2008 at 01:32:51PM -0500, Manoj Srivastava wrote:
>> Seems like there are patches stripping the kernel of these
>> non-free blobs. So, how much would out hardware support be degraded?
>> How many people are affected by these non-free drivers?
>
> The drm modules: Anything which includes an ATI or Matrox card and runs
> X. The network modules: Not that much, it is mostly old hardware. We
> already removed the bnx2x driver for the new Broadcom 10GE interfaces,
> which in fact is a really new one.
Thanks for the response. The DRM modules are need for 3D
acceleration, right? So the box can be installed, and is usable for
non-gaming purposes. The drm stuff can possibly be gotten from non
free, like we do nvidia accelerated drivers today?
If that is the case, the drm drivers should not be an obstacle.
manoj
who has not yet switched to the free drivers for nvidia cards yet
--
Information is the inverse of entropy.
Manoj Srivastava <sriv...@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Alexandre Oliva
Sorry if this breaks threading, I'm not on this list, I was merely
referred to the discussion through the archives. If you respond to
this e-mail, please address your replies directly to myself as well,
so that I can respond without further breaking threading.
I applaud Debian's willingness, even if hesitant and heated, to tackle
this issue.
I'm here to point out that there's some exaggeration and false
dilemmas being presented as objections to the liberation of the kernel
in Debian main.
I saw references to e100 and ATI video cards. Although it is true
that linux-libre and other proposed means to remove their blobs might
cause some hardware to malfunction or fail, I haven't come across any
such hardware myself. I do have computers with e100 network cards and
ATI video cards, and they keep on working just fine with linux-libre.
Now, I don't know whether the absence of the firmware causes degraded
functionality, or whether it is just not necessary for the specific
hardware I own. But assuming that the removal of these pieces of
firmware would break all instances of said hardware is a mistake.
As for the false dilemmas... It just doesn't hold that offering a
Free kernel in main leaves users out in the cold. As much as I oppose
the notion of distributing non-Free Software, if Debian doesn't, you
might as well *also* ship an encumbered kernel in non-Free, just like
you're planning on shipping stand-alone non-Free firmware, as well as
non-Free firmware that was, let's say, disintegrated :-) from the
kernel proper. Having yet another kernel, and having it in non-free,
might not be as convenient, but having only the non-free kernel, and
in main while at that, amounts to betraying your foundations, denying
freedom to your users, and fooling some of them on top of that.
Please think very carefully before doing that.
Anyhow, if you do decide to ship a Free kernel in Debian GNU/Linux
main, please remember that cleaning up the kernel binaries is only
part of the work; if the corresponding sources still contain the
non-Free blobs, whoever distributes the binaries is also required to,
at the very least, (pass on an) offer to distribute non-Free Software.
That's why we prepare cleaned-up Linux-libre tarballs, that distros
can use directly, or build upon, applying whatever patches they'd have
otherwise applied on the non-Free kernel published at kernel.org.
Thanks, and keep up the good work,
--
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}
FSFLA Board Member ¡Sé Libre! => http://www.fsfla.org/
Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org}
Frans Pop
> I am *happy* to code an acceptable solution, but I regard "not support
> the hardware for installation" as acceptable.
I'm very glad that history has shown most developers disagree with you.
> So I can upload an NMU right now that fixes the problem?
No, it's not OK. See <20081021094...@sirena.org.uk> for a good
description of an approach that would be welcome.
William Pitcock
> On Tue, 2008-10-21 at 15:22 +0000, Anthony Towns wrote:
> > Thomas: your continued inaction and unwillingness to code an acceptable
> > solution to this issue, in spite of being aware of the problem since
> > at least 2004 -- over four years ago! -- means we will continue to do
> > releases with non-free software.
>
> I am *happy* to code an acceptable solution, but I regard "not support
> the hardware for installation" as acceptable.
Luckily very few others do.
Failing to support anything that was infact, supported by Etch, that
isn't absolutely positively ancient, is a regression.
>
> I ask simply that the project's standards be *applied*, or that at the
> very least, we have a resolution as we did before. And yes, I would
> likely vote against it, as I did before. But in a democratic system,
> people generally are well advised to accept the result of past votes
> gracefully and work towards the next one. That's what I did; my vote
> did not carry the day last time, and I have not objected about that
> decision since. But I *do* object to the apparent new rule that the
> ftpmasters and release engineers are now empowered to ignore DFSG
> violations without any review by anyone else.
>
> And now we have people saying, "hey, let's exempt firmware from the
> DFSG!" again, even though we have a GR on topic which decided that, no,
> firmware counts.
Shipping Lenny within a reasonable timeframe is more important than
firmware. If the release managers feel that firmware bugs should be
tagged lenny-ignore, than it is because they feel that fixing these bugs
would likely delay the Lenny release too long. Note that Debian is
already distributing this stuff in sid, so why give Lenny special
treatment?
If we waited for a release to be 100% perfect, it will likely take
several more years. The good news is that the amount of inline firmware
in the kernel is decreasing. So, eventually, all non-DFSG
redistributable firmware can belong in firmware-nonfree.
But that goal will simply not be realized before Lenny is released, if
we intend to ship Lenny anytime soon.
>
> > "Hey, you've had four years; we're just going to keep releasing until
> > you fix the bug."
> >
> > Hint: you're not being held hostage by anyone, seriously. You know how
> > you can tell? Two words: Stockholm syndrome.
>
> So I can upload an NMU right now that fixes the problem? That will be
> ok?
If the NMU involves removing support for hardware, then no, the NMU's
solution would be in my opinion unacceptable, and hopefully enough
people agree that it would be rejected.
The correct solution here would be to work with the kernel team and
derive a list of acceptable goals that still result in Lenny being
shipped in a reasonable timeframe.
William
Thomas Bushnell BSG
I see. So the previous statement that "nobody is standing in the way"
of a fix is simply not so. People certainly are standing in the way.
Thomas Bushnell BSG
> If we waited for a release to be 100% perfect, it will likely take
> several more years. The good news is that the amount of inline firmware
> in the kernel is decreasing. So, eventually, all non-DFSG
> redistributable firmware can belong in firmware-nonfree.
Do we have an ironclad commitment to not add any additional non-DFSG
firmware, period, no matter what? I would accept a compromise which
guaranteed an increasing slope. But not a back-and-forth thing. Your
reply focuses on regression issues, so is that really sufficient? We
guarantee that, say, there will always be *less* non-DFSG firmware in
each release, and we guarantee that there will never be *new* non-DFSG
firmware.
> If the NMU involves removing support for hardware, then no, the NMU's
> solution would be in my opinion unacceptable, and hopefully enough
> people agree that it would be rejected.
Thought so. So the claim that "nobody is standing in the way" was
simply false. People are standing in the way of a simple fix for a
simple bug, and insisting on a more complex fix. I agree completely
that the more complex fix is better, but it is simply not true that
nobody is standing in the way of a fix. Rather, they have declared that
only one sort of fix is tolerable, and mostly refused to discuss the
question.
Kalle Kivimaa
exhaustive list of non-free bits in main, and make it our goal that the
list gets smaller between each release and not to add anything to
that list?
--
* Sufficiently advanced magic is indistinguishable from technology (T.P) *
* PGP public key available @ http://www.iki.fi/killer *
Frans Pop
> I see. So the previous statement that "nobody is standing in the way"
> of a fix is simply not so. People certainly are standing in the way.
That's nonsense. Uncoordinated NMUs are never acceptable for packages that
are in general actively maintained (which the kernel is), especially not
when it concerns controversial or technically complex changes [1].
Doing so would be a violation of basic NMU policy.
[1] This would seem to be both.
William Pitcock
> On Tue, 2008-10-21 at 14:59 -0500, William Pitcock wrote:
> > If we waited for a release to be 100% perfect, it will likely take
> > several more years. The good news is that the amount of inline firmware
> > in the kernel is decreasing. So, eventually, all non-DFSG
> > redistributable firmware can belong in firmware-nonfree.
>
> Do we have an ironclad commitment to not add any additional non-DFSG
> firmware, period, no matter what? I would accept a compromise which
> guaranteed an increasing slope. But not a back-and-forth thing. Your
> reply focuses on regression issues, so is that really sufficient? We
> guarantee that, say, there will always be *less* non-DFSG firmware in
> each release, and we guarantee that there will never be *new* non-DFSG
> firmware.
Unfortunately, those who contribute to Debian must be dedicated to
ensuring future releases of Debian support the latest available hardware
at time of release.
If those drivers require firmware, then we can work to ensure that they
use the kernel's firmware loading framework. This is a cause that is a
good idea for many practical reasons excluding ensuring the firmware is
segregated to firmware-nonfree.
However, not supporting the latest 3ware RAID card due to non-free
firmware, as an example, would be unacceptable, considering Debian's
strong foundation in being run on servers.
Likewise, failing to support the latest 3D hardware or audio hardware
when DFSG-free drivers are available, but depend on non-DFSG firmware,
will lose Debian users on desktop hardware as well.
That said, Debian release cycles are fairly long, so there's time to
make sure things are implemented right in the future.
>
> > If the NMU involves removing support for hardware, then no, the NMU's
> > solution would be in my opinion unacceptable, and hopefully enough
> > people agree that it would be rejected.
>
> Thought so. So the claim that "nobody is standing in the way" was
> simply false. People are standing in the way of a simple fix for a
> simple bug, and insisting on a more complex fix. I agree completely
> that the more complex fix is better, but it is simply not true that
> nobody is standing in the way of a fix. Rather, they have declared that
> only one sort of fix is tolerable, and mostly refused to discuss the
> question.
People are not standing in your way as long as it does not cause
regressions or break support for current hardware that people may wish
to use.
William
Franklin PIAT
> On Tue, Oct 21 2008, Aurelien Jarno wrote:
>
> > On Mon, Oct 20, 2008 at 07:30:23PM +0200, Robert Millan wrote:
> >> On Mon, Oct 20, 2008 at 07:16:12PM +0200, Josselin Mouette wrote:
> >> >
> >> > You cannot ask, so late in the release process,
> >>
> >> Some of these bugs have been known for *years*. In one of them, I even got
> >> a reply saying something along the lines of "I was expecting this one".
> >>
> >
> > Debian is violating the DFSG by using a non-DFSG license for its
> > website (see bug#238245). As the bug is opened for *years*, I suggest
> > we proceed with the removal of the website.
>
> Yes, this is another thing we need to fix.
>
> > Any volunteer to work on that?
>
> First things first: Where do I record the fact that any
> contribution I have made to the web site or the wiki may be licensed
> under the GPL?
As announced during DC8, the wiki is going to be relicensed, that's on
our plan (It's just that some other stuffs have my attention ATM).
The first step is to choose the license, so I can't give you an URL.
Please, don't remove the wiki yet ! (but we will remove non-free stuffs
from the wiki).
Franklin
Thomas Bushnell BSG
The claim was, hey, nobody is stopping anyone from fixing it, if it's
not fixed, it's lame for people to complain, they should have fixed it.
But, in fact, fixes are not welcome from the team. They have raised a
major roadblock, allowing only one kind of fix which requires a lot of
work, and rejecting anything simpler.
Yes, certainly the team has the right to make such roadblocks if they
think it best, in principle. But then that's what's happening: they are
standing in the way of implementing a quicker simpler fix.
You can either blame people for not uploading their own fix or prohibit
them from doing so, but you can't do both at the same time.
Frans Pop
> But, in fact, fixes are not welcome from the team. They have raised a
> major roadblock, allowing only one kind of fix which requires a lot of
> work, and rejecting anything simpler.
Ever hear of the Technical Committee?
Thomas Bushnell BSG
> Would it be a good compromise between SCs #1, #3 and #4 if we made an
> exhaustive list of non-free bits in main, and make it our goal that the
> list gets smaller between each release and not to add anything to
> that list?
I would be entirely happy with that. But I have just been told by
William Pitcock that apparently we are required somehow to support new
hardware with non-free software too. So it's not a decreasing list,
it's an accordion list with no real commitment to the DFSG at all.
Thomas
Thomas Bushnell BSG
> Unfortunately, those who contribute to Debian must be dedicated to
> ensuring future releases of Debian support the latest available hardware
> at time of release.
No matter what our principles are? Wow. Why are we not equally
committed to supporting the latest proprietary codecs?
William Pitcock
> On Tue, 2008-10-21 at 23:28 +0300, Kalle Kivimaa wrote:
> > Would it be a good compromise between SCs #1, #3 and #4 if we made an
> > exhaustive list of non-free bits in main, and make it our goal that the
> > list gets smaller between each release and not to add anything to
> > that list?
>
> I would be entirely happy with that. But I have just been told by
> William Pitcock that apparently we are required somehow to support new
> hardware with non-free software too. So it's not a decreasing list,
> it's an accordion list with no real commitment to the DFSG at all.
Do not put words into my mouth. I simply stated that user experience is
an important factor, and that if free drivers (*FREE*) which depend on
non-free firmware are available, and the firmware is inline, then it
should not block Lenny's release.
William
Thomas Bushnell BSG
This is a technical dispute? Whether your packages need to comply with
the DFSG?
Thomas Bushnell BSG
Huh? So you would be willing to agree to a rule that we never add
anything new to the list of non-free bits?
Frans Pop
> This is a technical dispute? Whether your packages need to comply with
> the DFSG?
Isn't a dispute about alternative fixes for a bug a technical dispute?
I thought that was your point.
The violation itself is not a matter for the TC (although it could be if
the maintainer argued that it wasn't a violation at all). But whether
your proposed fix is suitable for Debian when the maintainer prefers a
different type of fix certainly is. And it would even be a matter for the
TC to decide whether the maintainer is right in rejecting your fix as an
intermediate solution.
And if the TC agrees with the maintainer and you still want (to help get)
the bug fixed, your only option will be to code the more complex fix.
Anyway, I'm having a very hard time to take you seriously on any policy
compliance issues as you are still CCing me on Debian listmail in
violation of the Debian list policy despite a request I sent you earlier
privately.
EOD for me.
William Pitcock
> On Tue, 2008-10-21 at 16:27 -0500, William Pitcock wrote:
> > On Tue, 2008-10-21 at 14:20 -0700, Thomas Bushnell BSG wrote:
> > > On Tue, 2008-10-21 at 23:28 +0300, Kalle Kivimaa wrote:
> > > > Would it be a good compromise between SCs #1, #3 and #4 if we made an
> > > > exhaustive list of non-free bits in main, and make it our goal that the
> > > > list gets smaller between each release and not to add anything to
> > > > that list?
> > >
> > > I would be entirely happy with that. But I have just been told by
> > > William Pitcock that apparently we are required somehow to support new
> > > hardware with non-free software too. So it's not a decreasing list,
> > > it's an accordion list with no real commitment to the DFSG at all.
> >
> > Do not put words into my mouth. I simply stated that user experience is
> > an important factor, and that if free drivers (*FREE*) which depend on
> > non-free firmware are available, and the firmware is inline, then it
> > should not block Lenny's release.
>
> Huh? So you would be willing to agree to a rule that we never add
> anything new to the list of non-free bits?
In the kernel itself, yes. Provided that:
* the kernel framework for loading firmware is used for drivers
depending on non-free firmware, and
* that firmware is available in non-free via firmware-nonfree
Infact, once I have time, I intend to start pushing patches upstream to
make this happen.
But this is going to take another kernel release cycle... if we intend
to release Lenny with 2.6.26, than this is not an option.
For hardware where this is an unacceptable solution, rewriting the
driver to not use the firmware may still be possible.
William
Ean Schuessler
> On Tue, 2008-10-21 at 16:00 -0500, William Pitcock wrote:
> > Unfortunately, those who contribute to Debian must be dedicated to
> > ensuring future releases of Debian support the latest available hardware
> > at time of release.
Really do have to disagree there. We should absolutely preferentially support quality hardware that facilitate user control.
>From a purely practical standpoint, there may come a time (because of evolutions in nanotech or who knows what) where certain type of digital technologies have strong controls that must be honored in order to preserve the safety of the general public. Given that scenerio I think we would have to be "100% free" and "100% obey the law". I think we can leave it to others to break the law for us (or, preferrably, secure legal permissions through proper channels). We don't need to distribute binary blobs to have a useful foundation for building other things.
If I was going to suggest any kind of change to the Social Contract at this point it would be:
6. Debian will obey the law
We acknowledge that our users live in real communities in the real world. We will support the needs of our users to comply with the laws that are applicable in the places where they use their software. We will strive to create the most usable operating system legally possible for our users. Within the boundaries of our resources we will work with our developers to track and adapt the changes necessary for them to comply with the laws and rules of their local authority. In the jurisdiction of authorities which are antagonistic to the cause of Free Software we will work within the boundaries of the law to promote change to a more open system.
...
Obviously, we can't be in the position of asking our donors or our users to purposefully break the law. Where law and logistics make it impossible to be "completely free" we must strive to be as "free as legally possible" and work to promote positive change.
--
Ean Schuessler, CTO Brainfood.com
e...@brainfood.com - http://www.brainfood.com - 214-720-0700 x 315
William Pitcock
> William Pitcock <nen...@sacredspiral.co.uk> writes:
>
> > Unfortunately, those who contribute to Debian must be dedicated to
> > ensuring future releases of Debian support the latest available
> > hardware at time of release.
>
> special reading of the vague “our users” commitment, or do you get
> this dedication from all Debian contributors some other way?
>
> Does that dedication somehow override every DD's explicit commitment
> to ensuring Debian is 100% DFSG-free in the Social Contract?
I worded that rather badly. You should imply "within acceptable terms of
the DFSG" here... in this case, putting stuff in the nonfree firmware
package in non-free is an acceptable solution.
William
Ben Finney
> Unfortunately, those who contribute to Debian must be dedicated to
> ensuring future releases of Debian support the latest available
> hardware at time of release.
That's news to me. Where is such a dedication required? Is it some
special reading of the vague “our users” commitment, or do you get
this dedication from all Debian contributors some other way?
Does that dedication somehow override every DD's explicit commitment
to ensuring Debian is 100% DFSG-free in the Social Contract?
--
\ “Two paradoxes are better than one; they may even suggest a |
`\ solution.” —Edward Teller |
_o__) |
Ben Finney
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
Thomas Weber
May I suggest that people cool down a little bit and don't assume the
worst from the other participants of the discussion.
Shit happens[1], throwing mud doesn't improve the atmosphere at all.
[1] That includes, but is not limited to, bugs in packages and
suboptimal wording in e-mails.
Thomas
Gunnar Wolf
>
> If I was going to suggest any kind of change to the Social Contract
> at this point it would be:
>
> 6. Debian will obey the law
>
> We acknowledge that our users live in real communities in the real
> world. We will support the needs of our users to comply with the
> laws that are applicable in the places where they use their
> software. We will strive to create the most usable operating system
> legally possible for our users. Within the boundaries of our
> resources we will work with our developers to track and adapt the
> changes necessary for them to comply with the laws and rules of
> their local authority. In the jurisdiction of authorities which are
> antagonistic to the cause of Free Software we will work within the
> boundaries of the law to promote change to a more open system.
>
> ...
>
> Obviously, we can't be in the position of asking our donors or our
> users to purposefully break the law. Where law and logistics make it
> impossible to be "completely free" we must strive to be as "free as
> legally possible" and work to promote positive change.
Umh, problem is the myriad of jurisdictions all over the world. This
would very easily become unfeasible. In the end, it ends up being each
user's responsability to obey the law the best way he can. Debian
helps as much as possible by only using valid, free and compatible
licensing schemes - but if in West Namibia it becomes illegal to
digitally manipulate photographies, we won't stop shipping photo
manipulation programs.
Greetings,
--
Gunnar Wolf - gw...@gwolf.org - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
Thomas Bushnell BSG
> I worded that rather badly. You should imply "within acceptable terms of
> the DFSG" here... in this case, putting stuff in the nonfree firmware
> package in non-free is an acceptable solution.
Of course; that's an excellent solution. Right now, the failure to have
that solution implemented is being used as an excuse for violating SC#1.
Thomas