FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 05-22-2008, 12:35 AM
Alexandre Oliva
 
Default Plan for tomorrows (20080522) FESCO meeting

On May 21, 2008, Josh Boyer <jwboyer@gmail.com> wrote:

> So work with upstream to get them removed or pushed to separate
> firmware packages.

It's been tried before. I gather upstream is not interested in
achieving a 100% Free Software kernel tarball. It's in conflict with
our stated mission. Where do we go from that point, when upstream is
not cooperative and there is a drop-in alternative.

> Given your preference to not work in a manner which would be compatible
> with Fedora Engineering practices,

This is a very unfair assumption. I just have had access to facts
that you apparently didn't. Either that or you're being intentionally
obnoxious in sending me down this wild goose chase.

> I'm not sure there is a way out. However perhaps you can enlist
> some help from someone that would be willing to do that.

Finding someone else to do it might enable more patches to be posted,
but it wouldn't make it possible to achieve the goal.

>> One of us is missing something. How would a comps group prevent the
>> accidental installation of say non-Free kernel or firmware packages
>> brought in through unintended dependencies, for a user who wants to
>> make sure no such software is installed, for example?

> Fine, a fair point. Create a Free spin via a kickstart file.

Still no use, unless the spin comes with its own separate repository,
never contaminated by non-Free Software. At which point users might
as well switch to BLAG.

> Having that virtual package is more pain to maintain than a ks file

Err... The only person I know who has volunteered to maintain this
package disagrees with this assessment, especially because the ks file
does not even begin to address the longer-term goal of enabling a user
to avoid the installation of non-Free Software on his system (install
time and updates over time), rather than a short-term goal of avoiding
the inclusion of non-Free Software in one particular spin.

>> And largely misunderstood while at that. Not by everyone who objected
>> to it, for sure.

> I don't think there's been a large misunderstanding. Simply two
> differing opinions on the matter.

Like, a number of people vehemently objected to the idea of replacing
the current kernel with linux-libre. I hadn't proposed anything even
close to it. That's a large misunderstanding to me.

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

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-22-2008, 01:22 AM
Josh Boyer
 
Default Plan for tomorrows (20080522) FESCO meeting

On Wed, 21 May 2008 21:28:21 -0300
Alexandre Oliva <aoliva@redhat.com> wrote:

> On May 21, 2008, Josh Boyer <jwboyer@gmail.com> wrote:
>
> > Ok, then I'll call it an alternate kernel package. Which we still
> > aren't going to allow.
>
> > However doing that with an alternative kernel
> > package isn't something that sits well.
>
> > I'm talking about having any alternate kernel, period.
>
> I have never opposed the idea of replacing the non-Free kernel Fedora
> ships today with linux-libre or any of its predecessors. I just
> thought proposing it as an alternative that I offered to maintain
> myself would generate less heat. Maybe I was mistaken.

I didn't say you were going to outright replace it. But having more
than one kernel package will not be allowed. It has been discussed in
the past for things not even related to kernel-libre.

josh

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-22-2008, 01:41 AM
Josh Boyer
 
Default Plan for tomorrows (20080522) FESCO meeting

On Wed, 21 May 2008 21:35:09 -0300
Alexandre Oliva <aoliva@redhat.com> wrote:

> On May 21, 2008, Josh Boyer <jwboyer@gmail.com> wrote:
>
> > So work with upstream to get them removed or pushed to separate
> > firmware packages.
>
> It's been tried before. I gather upstream is not interested in
> achieving a 100% Free Software kernel tarball. It's in conflict with
> our stated mission. Where do we go from that point, when upstream is
> not cooperative and there is a drop-in alternative.

Tough spot. I don't have an answer for you.

> > Given your preference to not work in a manner which would be compatible
> > with Fedora Engineering practices,
>
> This is a very unfair assumption. I just have had access to facts
> that you apparently didn't. Either that or you're being intentionally
> obnoxious in sending me down this wild goose chase.

I wouldn't send you on a goose chase. Can you point me to where you've
approached the upstream kernel maintainers about this?

> > I'm not sure there is a way out. However perhaps you can enlist
> > some help from someone that would be willing to do that.
>
> Finding someone else to do it might enable more patches to be posted,
> but it wouldn't make it possible to achieve the goal.

Because? If those patches get integrated, then wouldn't the parts you
find objectionable be gone?

> >> One of us is missing something. How would a comps group prevent the
> >> accidental installation of say non-Free kernel or firmware packages
> >> brought in through unintended dependencies, for a user who wants to
> >> make sure no such software is installed, for example?
>
> > Fine, a fair point. Create a Free spin via a kickstart file.
>
> Still no use, unless the spin comes with its own separate repository,
> never contaminated by non-Free Software. At which point users might
> as well switch to BLAG.

I don't understand that at all. You're suggesting that Fedora would
have to split up the actual repositories in order to accomplish your
goal?

> > Having that virtual package is more pain to maintain than a ks file
>
> Err... The only person I know who has volunteered to maintain this
> package disagrees with this assessment, especially because the ks file
> does not even begin to address the longer-term goal of enabling a user
> to avoid the installation of non-Free Software on his system (install
> time and updates over time), rather than a short-term goal of avoiding
> the inclusion of non-Free Software in one particular spin.

So you propose to have this virtual package updated constantly to
account for new dependencies on what _should_ be mostly firmware
packages as they show up? That seems tedious and error prone, but if
that's what you want you can certainly attempt it.

> >> And largely misunderstood while at that. Not by everyone who objected
> >> to it, for sure.
>
> > I don't think there's been a large misunderstanding. Simply two
> > differing opinions on the matter.
>
> Like, a number of people vehemently objected to the idea of replacing
> the current kernel with linux-libre. I hadn't proposed anything even
> close to it. That's a large misunderstanding to me.

I certainly didn't think you intended to _replace_ the main kernel
package. But I don't agree with even providing a completely different
alternative "kernel-libre" package. If it can't be built as a flavor
of the existing kernel package, then I don't see it being approved for
inclusion.

josh

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-22-2008, 02:01 AM
Toshio Kuratomi
 
Default Plan for tomorrows (20080522) FESCO meeting

Alexandre Oliva wrote:

On May 21, 2008, David Woodhouse <dwmw2@infradead.org> wrote:


On Wed, 2008-05-21 at 18:21 -0300, Alexandre Oliva wrote:

I believe I've already explained why I can't do that. I refuse to
distribute non-Free Software, and posting a patch that removes these
bits amounts to posting those very bits.



Really, that's a stupid objection. Just post it in ed form.


Assuming that's acceptable upstream. I sort of doubt it, but then, I
could send xdeltas as well, and if you've been part of the discussion,
then you probably know that that's not the only reason why I can't
take part in this plan.

Another I still haven't mentioned is that I have no interest in being
harrassed and verbally abused like the last discussion about freedom
issues I got into there.


Now, let me show you why this proposed plan is an impossible mission
that people are trying to drive me into. Consider this snippet from
http://www.fsfla.org/svn/fsfla/software/linux-libre/scripts/deblob-2.6.25

# SND_KORG1212 - Korg 1212 IO
clean_ifdef sound/pci/korg1212/korg1212.c CONFIG_SND_KORG1212_FIRMWARE_IN_KERNEL
clean_blob sound/pci/korg1212/korg1212-firmware.h

# SND_MAESTRO3 - ESS Allegro/Maestro3
clean_ifdef sound/pci/maestro3.c CONFIG_SND_MAESTRO3_FIRMWARE_IN_KERNEL

# SND_YMFPCI - Yamaha YMF724/740/744/754
clean_blob sound/pci/ymfpci/ymfpci_image.h
clean_ifdef sound/pci/ymfpci/ymfpci_main.c CONFIG_SND_YMFPCI_FIRMWARE_IN_KERNEL

clean_blob() removes long sequences of numbers, whereas clean_ifdef()
runs unifdef on the named file assuming the named variable is
undefined.

Could you honestly tell me, with a straight face and a reasonable
degree of assurance, that a patch that performs these actions stands
any chance whatsoever of being accepted upstream?

The firmwares are already optional to compile in, they can already be
loaded with the standard firmware loading machinery.

But while they're there, in the source code, distributing the kernel
sources amounts to distributing this non-Free Software, and
distributing binaries built out of these sources, even with these
options disabled, amounts to distributing the this non-Free Software
as part of the kernel sources or committing to distributing it over
the next 3 years. One way or another, it amounts to propagating the
problem.

If you tell me with a straight face that something like this stands a
chance of being accepted, I will give that a try. Otherwise, please
stop sending me in a mission that can't possibly be accomplished in a
way that achieves our shared goals of providing users with freedom,
with an operating system built out of only Free Software.

If Fedora cares about users' freedom, why would it follow and abide by
policies and dubious legal theories set by someone who doesn't and is
proud of it?

Does anyone think the issue about non-Free firmwares is any different
from the issue of non-Free drivers for nvidia cards, except for the
irrelevant detail that these different pieces of software can corrupt
the system (technically and morally) running on different CPUs?


Yes.

Seriously?


Yes.


Why do we bend over to keep compatibility and even distribute
binary-only code published by with vendors who have taken dubious
measures such as releasing code under the GPL without sources, or
explicitly contributing, to the kernel Linux, code under licenses
incompatible with its license, when an alternative is readily
available and looking forward to being included and with an active
maintainer that has already proved to be able to keep up even with
daily rawhide builds, and at the same time we proudly defend the
decision to ship X drivers that disregard (for good reasons)
compatibility with non-Free code?

What is it that appears to make these issues different? Is nVidia any
less supportive to our community than any of the other vendors who
push hardware and then push non-Free Software to enable their
customers to use the hardware at full power? Aren't we forgetting
something, or drawing a line at a point that is absolutely arbitrary
(which might be fine) and not in sync with our mission (with is
certainly not fine)?

There's free software as in legally licensed for us to use distribute
and modify and there's free software as in four freedoms free. Unless
I've missed something, the firmware in the kernel is licensed under the
GPLv2 and therefore it is legally licensed for us to use, distribute,
and modify. When dealing with firmware for driving a device, that's
enough for a lot of us. In fact, that's more than enough in some cases
as our policies [1]_ currently allow firmware packages that are freely
modifiable if they are redistributable.


.. [1]: http://fedoraproject.org/wiki/Licensing#BinaryFirmware

-Toshio

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-22-2008, 04:58 AM
Alexandre Oliva
 
Default Plan for tomorrows (20080522) FESCO meeting

On May 21, 2008, Josh Boyer <jwboyer@gmail.com> wrote:

> On Wed, 21 May 2008 21:35:09 -0300
> Alexandre Oliva <aoliva@redhat.com> wrote:

>> On May 21, 2008, Josh Boyer <jwboyer@gmail.com> wrote:

>> > Given your preference to not work in a manner which would be compatible
>> > with Fedora Engineering practices,

>> This is a very unfair assumption. I just have had access to facts
>> that you apparently didn't. Either that or you're being intentionally
>> obnoxious in sending me down this wild goose chase.

> I wouldn't send you on a goose chase.

Thank you.

> Can you point me to where you've approached the upstream kernel
> maintainers about this?

I haven't. I'm told others have, and have been ridiculed. From what
I gather from the LKML archives and personal experiences there, I have
no reason to disbelieve them.

>> > I'm not sure there is a way out. However perhaps you can enlist
>> > some help from someone that would be willing to do that.
>>
>> Finding someone else to do it might enable more patches to be posted,
>> but it wouldn't make it possible to achieve the goal.

> Because?

Because upstream doesn't want to achieve this goal, and actively
refuses to accept changes essential to get there.

> If those patches get integrated, then wouldn't the parts you find
> objectionable be gone?

Not all of them, no.

>> >> One of us is missing something. How would a comps group prevent the
>> >> accidental installation of say non-Free kernel or firmware packages
>> >> brought in through unintended dependencies, for a user who wants to
>> >> make sure no such software is installed, for example?

>> > Fine, a fair point. Create a Free spin via a kickstart file.

>> Still no use, unless the spin comes with its own separate repository,
>> never contaminated by non-Free Software. At which point users might
>> as well switch to BLAG.

> I don't understand that at all. You're suggesting that Fedora would
> have to split up the actual repositories in order to accomplish your
> goal?

No. I'm suggesting that a fedora-freedom package that conflicts with
the non-Free packages in the main repository would be a simpler way to
enable users to choose not to let non-Free Software sneak into their
computers.

> So you propose to have this virtual package updated constantly to
> account for new dependencies on what _should_ be mostly firmware
> packages as they show up?

Yup, except for the 'constantly'. Fortunately, there's not so much
non-Free stuff in Fedora. Yes, it is error-prone, and I'm all ears to
listen to to better suggestions on how to accomplish this. Ruling out
all non-Free Software from Fedora would certainly make this much
simpler, but I'm not going to count on that just yet ;-)

>> >> And largely misunderstood while at that. Not by everyone who objected
>> >> to it, for sure.
>>
>> > I don't think there's been a large misunderstanding. Simply two
>> > differing opinions on the matter.
>>
>> Like, a number of people vehemently objected to the idea of replacing
>> the current kernel with linux-libre. I hadn't proposed anything even
>> close to it. That's a large misunderstanding to me.

> I certainly didn't think you intended to _replace_ the main kernel
> package. But I don't agree with even providing a completely different
> alternative "kernel-libre" package. If it can't be built as a flavor
> of the existing kernel package, then I don't see it being approved for
> inclusion.

So much for http://www.linux-books.us/fedora_core_0001.php

Fedora Core is a complete desktop and server operating system
created entirely with open source software.

I'm pretty sure in the good old days something along these lines used
to be on Fedora's front page, and that Fedora's mission statement
didn't weasel out of it.

But I still see people advertising today that 'freedom is a feature'.
Unfortunately, it feels like it's buggy in several ways, and the bugs
reported in this regard get responses along the lines of
CLOSED/UPSTREAM and CLOSED/WONTFIX :-(

And 'infinite freedom' is like a bad joke :-(

Oh well...

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

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-22-2008, 05:18 AM
Alexandre Oliva
 
Default Plan for tomorrows (20080522) FESCO meeting

On May 21, 2008, Toshio Kuratomi <a.badger@gmail.com> wrote:

> Alexandre Oliva wrote:
>> On May 21, 2008, David Woodhouse <dwmw2@infradead.org> wrote:

>> Does anyone think the issue about non-Free firmwares is any different
>> from the issue of non-Free drivers for nvidia cards, except for the
>> irrelevant detail that these different pieces of software can corrupt
>> the system (technically and morally) running on different CPUs?

> Yes.

>> Seriously?

> Yes.

> There's free software as in legally licensed for us to use distribute
> and modify and there's free software as in four freedoms free. Unless
> I've missed something, the firmware in the kernel is licensed under
> the GPLv2 and therefore it is legally licensed for us to use,
> distribute, and modify.

I'm sorry to be the bearer of bad news, but you did indeed miss
something.

Have a look at the license for drivers/net/tokenring/3c359_microcode.h

2 /*
3 * The firmware this driver downloads into the tokenring card is a
4 * separate program and is not GPL'd source code, even though the Linux
5 * side driver and the routine that loads this data into the card are.
6 *
7 * This firmware is licensed to you strictly for use in conjunction
8 * with the use of 3Com 3C359 TokenRing adapters. There is no
9 * waranty expressed or implied about its fitness for any purpose.
10 */

This is just one out of some 30 examples of such licenses in the
kernel. And, heck, this one doesn't even grant permission for
redistribution. What are those Linux-no-libre guys thinking?


Anyhow... How does this relate with my question quoted above?

nVidia's video drivers are non-Free. firmware included in the kernel,
as well as the other redistributable firmware included separately in
Fedora, are non-Free.

The hair-splitters that try to invent an artificial difference based
on what CPU the code runs on don't only miss the point on supporting
unethical vendors, but also on their very amoral technical grounds for
introducing the artificial distinction: they're supposed to run on
*some* CPU on *some* users' machines, and since we don't know what
they're doing and they run in privileged mode (on whatever CPU they
run), they're at least in theory perfectly capable of wreaking havoc
on the entire system, and in fact some of them do.

So why the exception again? Because users can't live without them?
Well, sure some users can't. Nobody stops such users from being
informed by Fedora about the problems in their hardware and how to get
ahold of the hardware vendor to obtain some software (presumably
non-Free) that will get the hardware going. Fedora doesn't need to
carry such software, and Fedora doesn't need to promote or encourage
its use.

> .. [1]: http://fedoraproject.org/wiki/Licensing#BinaryFirmware

I'm well aware of that exception. Nowhere does it say "we must force
binary firmware onto every Fedora user's machine, and we must avoid at
all costs any attempts to enable users to prevent the installation of
such binary firwmare on their machines" :-)

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

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-22-2008, 08:24 AM
David Woodhouse
 
Default Plan for tomorrows (20080522) FESCO meeting

On Wed, 2008-05-21 at 20:53 -0300, Alexandre Oliva wrote:
> On May 21, 2008, David Woodhouse <dwmw2@infradead.org> wrote:
>
> > On Wed, 2008-05-21 at 18:21 -0300, Alexandre Oliva wrote:
> >> I believe I've already explained why I can't do that. I refuse to
> >> distribute non-Free Software, and posting a patch that removes these
> >> bits amounts to posting those very bits.
>
> > Really, that's a stupid objection. Just post it in ed form.
>
> Assuming that's acceptable upstream. I sort of doubt it,

Post them to me; I'll convert them to 'diff -u' for you and send them
on.

> Another I still haven't mentioned is that I have no interest in being
> harrassed and verbally abused like the last discussion about freedom
> issues I got into there.

That is best addressed by making sure you don't come across as a kook.
You need to make it clear that you're not just intending to remove stuff
and run away leaving it broken; for anything you change, you need to
make sure there is a viable working alternative. Saying "oh, but I don't
want to touch it" is a crappy excuse. If you don't want to touch it,
then get someone _else_ to do the work. But don't expect your ed-scripts
to be applied when they're actually causing regressions.

>
> Now, let me show you why this proposed plan is an impossible mission
> that people are trying to drive me into. Consider this snippet from
> http://www.fsfla.org/svn/fsfla/software/linux-libre/scripts/deblob-2.6.25
>
> # SND_KORG1212 - Korg 1212 IO
> clean_ifdef sound/pci/korg1212/korg1212.c CONFIG_SND_KORG1212_FIRMWARE_IN_KERNEL
> clean_blob sound/pci/korg1212/korg1212-firmware.h
>
> # SND_MAESTRO3 - ESS Allegro/Maestro3
> clean_ifdef sound/pci/maestro3.c CONFIG_SND_MAESTRO3_FIRMWARE_IN_KERNEL
>
> # SND_YMFPCI - Yamaha YMF724/740/744/754
> clean_blob sound/pci/ymfpci/ymfpci_image.h
> clean_ifdef sound/pci/ymfpci/ymfpci_main.c CONFIG_SND_YMFPCI_FIRMWARE_IN_KERNEL
>
> clean_blob() removes long sequences of numbers, whereas clean_ifdef()
> runs unifdef on the named file assuming the named variable is
> undefined.
>
> Could you honestly tell me, with a straight face and a reasonable
> degree of assurance, that a patch that performs these actions stands
> any chance whatsoever of being accepted upstream?

I'll tell you what I'd do to _improve_ its chances. Would that do?

What I'd do is augment the kernel's firmware class support so that users
can build firmware blobs into their kernel to be accessed through the
firmware class. So the ifdefs in the above code go away -- the user can
just choose to include the blobs in the kernel build or not, as they see
fit, and the driver just invokes the firmware loader and doesn't
actually _care_ whether the firmware comes from within the kernel or
from userspace.

Once you've done that, you (or your minion) can start moving all the
offending uses of firmware blobs over to the firmware class without
_any_ regressions at all, since they'll keep working without even
needing an initrd.

And after that, you can look at evicting the offending blobs from the
kernel altogether. Since Fedora uses an initrd anyway, we'd probably
choose not to build any of the blobs into the kernel, but to ship them
in a separate package(s). You can then just omit that package from your
compose.

I'm utterly uninterested in any response of "that sounds like work; I
just want to break things" or "I don't want to touch it". Those are the
responses which will get you "harassed and verbally abused" on lkml, or
just ignored by me.

--
dwmw2

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-22-2008, 09:55 AM
Alexandre Oliva
 
Default Plan for tomorrows (20080522) FESCO meeting

On May 21, 2008, Brian Pepple <bpepple@fedoraproject.org> wrote:

> On Wed, 2008-05-21 at 16:20 -0300, Alexandre Oliva wrote:
>> On May 21, 2008, Brian Pepple <bpepple@fedoraproject.org> wrote:
>>
>> . Permission to distribute under the mark 'Fedora' spins containing
>> kernel-libre packages, whose sole difference from identically-numbered
>> Fedora kernel builds is the removal of a few pieces of non-Free
>> Software.

> I've gone ahead and add the kernel-libre topic to the schedule for
> tomorrow. I've put it at the end of the agenda though, since I want to
> make sure we get to the other items on the schedule before we begin this
> discussion (since I'm guessing it will be fairly lengthy).

Thanks.

Here's the proposed feature I've just drafted up:
http://fedoraproject.org/wiki/Features/FedoraFreedom

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

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-22-2008, 10:11 AM
Rahul Sundaram
 
Default Plan for tomorrows (20080522) FESCO meeting

Alexandre Oliva wrote:

On May 21, 2008, Brian Pepple <bpepple@fedoraproject.org> wrote:


On Wed, 2008-05-21 at 16:20 -0300, Alexandre Oliva wrote:

On May 21, 2008, Brian Pepple <bpepple@fedoraproject.org> wrote:

. Permission to distribute under the mark 'Fedora' spins containing
kernel-libre packages, whose sole difference from identically-numbered
Fedora kernel builds is the removal of a few pieces of non-Free
Software.



I've gone ahead and add the kernel-libre topic to the schedule for
tomorrow. I've put it at the end of the agenda though, since I want to
make sure we get to the other items on the schedule before we begin this
discussion (since I'm guessing it will be fairly lengthy).


Thanks.

Here's the proposed feature I've just drafted up:
http://fedoraproject.org/wiki/Features/FedoraFreedom


You might want to attend the IRC meeting and participate in the
discussions regarding this proposal. Also try and pro actively address
the objections raised and answer them within the wiki page. Not everyone
in FESCo might have read the lengthy thread on the topic. IIRC, the
primary and perhaps only real objection is that you are proposing to
maintain a additional kernel package. Instead David Woodhouse, Alan Cox
and others have offered to act as a gateway between you and upstream
Linux community and remove the firmware out of the kernel in a way that
satisfies the requirement of both the parties instead of maintaining a
separate branch within Fedora.


Rahul

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-22-2008, 12:06 PM
Josh Boyer
 
Default Plan for tomorrows (20080522) FESCO meeting

On Thu, 22 May 2008 01:58:25 -0300
Alexandre Oliva <aoliva@redhat.com> wrote:

> > Can you point me to where you've approached the upstream kernel
> > maintainers about this?
>
> I haven't. I'm told others have, and have been ridiculed. From what
> I gather from the LKML archives and personal experiences there, I have
> no reason to disbelieve them.

Ok, but you said you had facts. Now you're telling me you only have
hearsay?

> >> > I'm not sure there is a way out. However perhaps you can enlist
> >> > some help from someone that would be willing to do that.
> >>
> >> Finding someone else to do it might enable more patches to be posted,
> >> but it wouldn't make it possible to achieve the goal.
>
> > Because?
>
> Because upstream doesn't want to achieve this goal, and actively
> refuses to accept changes essential to get there.

Pointers to this would be nice. Mailing list archives, IRC
conversations, anything.

> > If those patches get integrated, then wouldn't the parts you find
> > objectionable be gone?
>
> Not all of them, no.

?

> > I certainly didn't think you intended to _replace_ the main kernel
> > package. But I don't agree with even providing a completely different
> > alternative "kernel-libre" package. If it can't be built as a flavor
> > of the existing kernel package, then I don't see it being approved for
> > inclusion.
>
> So much for http://www.linux-books.us/fedora_core_0001.php

So much for having a productive conversation. You're avoiding my point
(or think it's entirely hopeless) and spewing rhetoric again.

Rehashing the same conversation to come to the same results isn't
something I'm inclined to do. David Woodhouse and Alan Cox have
offered to help you work with upstream in the past. If you choose to
not take that offer of help to accomplish your goals, that's fine.

josh

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 

Thread Tools




All times are GMT. The time now is 07:40 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ę2007 - 2008, www.linux-archive.org