4:20 p.m.
Well, I have nothing on the agenda for tomorrow's meeting at this
point. Thus, the entire meeting taking place at 17:00UTC in
#fedora-meeting will be an open floor, unless someone comes up with
something to discuss between now and then :).
12:20 a.m.
On Thu, May 28, 2009 at 5:20 PM, Jon Stanley wrote:
Well, I have nothing on the agenda for tomorrow's meeting at
this
point. Â Thus, the entire meeting taking place at 17:00UTC in
#fedora-meeting will be an open floor, unless someone comes up with
something to discuss between now and then :).
I would like to have a pre-review on this proposal before we work on it more:
http://fedoraproject.org/wiki/Features/FedoraStudio
The initial idea was to classify the Audio Creation applications. But
classifying just the Audio Creation applications and leaving the
Audio/Video players, Video Creation applications, etc untouched was
not going be good design. So we tried to come up with a unified
solution, which might still need some polish. This has been discussed
in the fedora-music list this month:
https://www.redhat.com/archives/fedora-music-list/2009-May/msg00020.html
Please express your opinions about this little project.
Thanks,
Orcan
3:33 a.m.
On Thu May 28 2009, Jon Stanley wrote:
Well, I have nothing on the agenda for tomorrow's meeting at
this
point. Thus, the entire meeting taking place at 17:00UTC in
#fedora-meeting will be an open floor, unless someone comes up with
something to discuss between now and then :).
There is a proposed Feature that connot be completed because kernel module
packages are prohibited in Fedora:
https://fedoraproject.org/wiki/Features/VirtualBox
The Feature Wrangler told me, that the current feature process[0] cannot
handle this situation, because feature pages hang around until they are
excepted. But I guess that infiltrating FESCo to get kernel module packages
back into Fedora is not was is expected to finish the feature. ;-)
So if only FESCo can adjust the feature process, please update it to include
the case of unfinishable features.
Regards
Till
[0] https://fedoraproject.org/wiki/Features/Policy/Process
6:23 a.m.
On Fri, 2009-05-29 at 10:33 +0200, Till Maas wrote:
There is a proposed Feature that connot be completed because kernel
module
packages are prohibited in Fedora:
https://fedoraproject.org/wiki/Features/VirtualBox
Maybe the necessary bits can be included in the Fedora kernel package
itself?
--
Jussi Lehtola
Fedora Project Contributor
jussilehtola(a)fedoraproject.org
6:29 a.m.
On Fri, May 29, 2009 at 02:23:23PM +0300, Jussi Lehtola wrote:
On Fri, 2009-05-29 at 10:33 +0200, Till Maas wrote:
> There is a proposed Feature that connot be completed because kernel module
> packages are prohibited in Fedora:
> https://fedoraproject.org/wiki/Features/VirtualBox
Maybe the necessary bits can be included in the Fedora kernel package
itself?
That's only likely to happen if the virtualbox code gets included in the
upstream kernel.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
6:29 a.m.
On Fri, May 29, 2009 at 1:23 PM, Jussi Lehtola
<jussilehtola(a)fedoraproject.org> wrote:
On Fri, 2009-05-29 at 10:33 +0200, Till Maas wrote:
> There is a proposed Feature that connot be completed because kernel module
> packages are prohibited in Fedora:
> https://fedoraproject.org/wiki/Features/VirtualBox
Maybe the necessary bits can be included in the Fedora kernel package
itself?
For this they have to be upstream or atleast heading for upstream inclusion.
6:36 a.m.
On Fri, May 29, 2009 at 10:33:19AM +0200, Till Maas wrote:
On Thu May 28 2009, Jon Stanley wrote:
> Well, I have nothing on the agenda for tomorrow's meeting at this
> point. Thus, the entire meeting taking place at 17:00UTC in
> #fedora-meeting will be an open floor, unless someone comes up with
> something to discuss between now and then :).
There is a proposed Feature that connot be completed because kernel module
packages are prohibited in Fedora:
https://fedoraproject.org/wiki/Features/VirtualBox
The Feature Wrangler told me, that the current feature process[0] cannot
handle this situation, because feature pages hang around until they are
excepted. But I guess that infiltrating FESCo to get kernel module packages
back into Fedora is not was is expected to finish the feature. ;-)
So if only FESCo can adjust the feature process, please update it to include
the case of unfinishable features.
I don't see a problem.
If the Feature owner cares enough to keep proposing it, then FESCo will keep
reviewing it. Technical items change over time. Perhaps the VirtualBox
module will make it into the upstream kernel and the Feature will be viable.
Or perhaps a future FESCo will revist kmods.
If the Feature owner doesn't care, then they can delete the page. Either way,
I don't see what the problem is with having it sit in the FeaturePageIncomplete
category.
josh
8:01 a.m.
On Fri May 29 2009, Josh Boyer wrote:
I don't see a problem.
Imho outdated content reduces the quality of the wiki, therefore there should
be some garbage collection.
If the Feature owner cares enough to keep proposing it, then FESCo
will
keep reviewing it. Technical items change over time. Perhaps the
VirtualBox module will make it into the upstream kernel and the Feature
will be viable. Or perhaps a future FESCo will revist kmods.
Did you look at the content of the feature page? Even in the very unlikely
case that it may be included in Fedora in the future, Fedora will probably be
the last distribution to include it, so it is also very unlikely that it even
meats the Feature criteria. And if it does, there are only four sentences in
the Feature page, that were not in the template.
If the Feature owner doesn't care, then they can delete the page.
Either
way, I don't see what the problem is with having it sit in the
FeaturePageIncomplete category.
It seems more to me, that the Feature owner does not care, because the package
is very incomplete and I got no response from my comment in December 2008 that
Virtualbox won't make it into Fedora. Btw. how does the Feature owner delete
the page? It seems to me, that this is not easily possible using the wiki
interface.
Regards
Till
8:14 a.m.
Till Maas, Fri, 29 May 2009 15:01:29 +0200:
It seems more to me, that the Feature owner does not care, because
the
package is very incomplete and I got no response from my comment in
December 2008 that Virtualbox won't make it into Fedora. Btw. how does
the Feature owner delete the page? It seems to me, that this is not
easily possible using the wiki interface.
Moreover, it has been included in The Repository Which Shall Not Be Named.
Matěj
8:26 a.m.
On 29.05.2009 15:14, Matej Cepl wrote:
Till Maas, Fri, 29 May 2009 15:01:29 +0200:
> It seems more to me, that the Feature owner does not care, because the
> package is very incomplete and I got no response from my comment in
> December 2008 that Virtualbox won't make it into Fedora. Btw. how does
> the Feature owner delete the page? It seems to me, that this is not
> easily possible using the wiki interface.
Moreover, it has been included in The Repository Which Shall Not Be Named.
Which is always glad if things can get moved to Fedora sooner or later ;-)
CU
knurd
8:30 a.m.
On Fri May 29 2009, Matej Cepl wrote:
Till Maas, Fri, 29 May 2009 15:01:29 +0200:
> It seems more to me, that the Feature owner does not care, because the
> package is very incomplete and I got no response from my comment in
> December 2008 that Virtualbox won't make it into Fedora. Btw. how does
> the Feature owner delete the page? It seems to me, that this is not
> easily possible using the wiki interface.
Moreover, it has been included in The Repository Which Shall Not Be Named.
Yes, maybe I should have mentioned this, too. It allows to complete the
feature shortly after FESCo accepts it, because the packages only need to be
imported. Iirc the people involved are already Fedora packagers and therefore
the review is also already kind of done.
Regards
Till
8:30 a.m.
Matej Cepl wrote:
Moreover, it has been included in The Repository Which Shall Not Be
Named.
You mean we should not name RPM Fusion? Or link to http://rpmfusion.org/ ?
Well, maybe I'll make an effort not to name RPM Fusion. But then again, I
think I actually won't make an effort not to name RPM Fusion, because the
content in RPM Fusion is not illegal around here. Oops, how many times did
RPM Fusion appear in this paragraph? ;-)
Kevin Kofler
8:44 a.m.
On Fri, May 29, 2009 at 03:01:29PM +0200, Till Maas wrote:
On Fri May 29 2009, Josh Boyer wrote:
> I don't see a problem.
Imho outdated content reduces the quality of the wiki, therefore there should
be some garbage collection.
> If the Feature owner cares enough to keep proposing it, then FESCo will
> keep reviewing it. Technical items change over time. Perhaps the
> VirtualBox module will make it into the upstream kernel and the Feature
> will be viable. Or perhaps a future FESCo will revist kmods.
Did you look at the content of the feature page? Even in the very unlikely
Yes, I did.
case that it may be included in Fedora in the future, Fedora will
probably be
the last distribution to include it, so it is also very unlikely that it even
meats the Feature criteria. And if it does, there are only four sentences in
the Feature page, that were not in the template.
Yep.
> If the Feature owner doesn't care, then they can delete the
page. Either
> way, I don't see what the problem is with having it sit in the
> FeaturePageIncomplete category.
It seems more to me, that the Feature owner does not care, because the package
is very incomplete and I got no response from my comment in December 2008 that
Virtualbox won't make it into Fedora. Btw. how does the Feature owner delete
That seems to be a simple case of a page requiring wiki gardening. Seriously,
if we have to have a FESCo policy to allow the deletion of stale wiki pages
(Feature or not), then we have gone wrong somewhere.
So I suggest we just mark it for deletion and if the Feature owner cares he'll
unmark it.
the page? It seems to me, that this is not easily possible using the
wiki
interface.
https://fedoraproject.org/wiki/Help:Editing#Deleting_Pages
josh
11:52 p.m.
Till Maas said the following on 05/29/2009 06:01 AM Pacific Time:
On Fri May 29 2009, Josh Boyer wrote:
> I don't see a problem.
Imho outdated content reduces the quality of the wiki, therefore there should
be some garbage collection.
> If the Feature owner cares enough to keep proposing it, then FESCo will
> keep reviewing it. Technical items change over time. Perhaps the
> VirtualBox module will make it into the upstream kernel and the Feature
> will be viable. Or perhaps a future FESCo will revist kmods.
Did you look at the content of the feature page? Even in the very unlikely
case that it may be included in Fedora in the future, Fedora will probably be
the last distribution to include it, so it is also very unlikely that it even
meats the Feature criteria. And if it does, there are only four sentences in
the Feature page, that were not in the template.
> If the Feature owner doesn't care, then they can delete the page. Either
> way, I don't see what the problem is with having it sit in the
> FeaturePageIncomplete category.
It seems more to me, that the Feature owner does not care, because the package
is very incomplete and I got no response from my comment in December 2008 that
Virtualbox won't make it into Fedora. Btw. how does the Feature owner delete
the page? It seems to me, that this is not easily possible using the wiki
interface.
Try this :)
https://fedoraproject.org/wiki/FedoraProject:Deletion
8:33 a.m.
Josh Boyer wrote:
Or perhaps a future FESCo will revist kmods.
FWIW, I'd certainly vote for a proposal to allow kmods if I get into FESCo
and may even bring such a proposal in front of the new FESCo (though IMHO
it should not be the old regime with explicit FESCo approval for each, that
didn't make any sense, instead there should be no restrictions other than a
license compatible with that of the kernel, and of course the restrictions
applying to all packages).
Kevin Kofler
8:54 a.m.
On Fri, 29 May 2009, Kevin Kofler wrote:
Josh Boyer wrote:
> Or perhaps a future FESCo will revist kmods.
FWIW, I'd certainly vote for a proposal to allow kmods if I get into FESCo
and may even bring such a proposal in front of the new FESCo (though IMHO
it should not be the old regime with explicit FESCo approval for each, that
didn't make any sense, instead there should be no restrictions other than a
license compatible with that of the kernel, and of course the restrictions
applying to all packages).
and if I get elected to fesco I'll make sure to counter any vote for kmods
with a vote against them.
kmods are a disaster area and proof of this can be found in the near
constant stream of "bugs" related to people's systems broken by them in
terms of depsolving for them.
-sv
9:49 a.m.
On Fri, May 29, 2009 at 03:33:37PM +0200, Kevin Kofler wrote:
Josh Boyer wrote:
> Or perhaps a future FESCo will revist kmods.
FWIW, I'd certainly vote for a proposal to allow kmods if I get into FESCo
and may even bring such a proposal in front of the new FESCo (though IMHO
it should not be the old regime with explicit FESCo approval for each, that
didn't make any sense, instead there should be no restrictions other than a
license compatible with that of the kernel, and of course the restrictions
applying to all packages).
Could someone dispassionately summarise the reasons why kmods were
rejected in the first place? I assume the reason was the overhead of
maintaining and updating out-of-tree kernel patches?
Rich.
9:53 a.m.
Richard W.M. Jones (rjones(a)redhat.com) said:
> FWIW, I'd certainly vote for a proposal to allow kmods if I
get into FESCo
> and may even bring such a proposal in front of the new FESCo (though IMHO
> it should not be the old regime with explicit FESCo approval for each, that
> didn't make any sense, instead there should be no restrictions other than a
> license compatible with that of the kernel, and of course the restrictions
> applying to all packages).
Could someone dispassionately summarise the reasons why kmods were
rejected in the first place? I assume the reason was the overhead of
maintaining and updating out-of-tree kernel patches?
- Overhead of maintenance and updating
- Real-life experience of the existing kmod packages at the time *never* being
up to date with the kernel
- As part of 'staying close to upstream', kmods... aren't
- It provides a crappy user experience with users, where they'll be stuck
unable to upgrade, or boot, or use whatever functionality, until the
maintainer is able to fix any issues with their kmod (as they will break
with kernel changes)
- Increased maintenance for the kernel team, which they don't want (similar
to the compat package policy)
- If a driver is headed upstream, and is needed... just add it to the kernel
package proper
Bill
10:27 a.m.
On Fri, 2009-05-29 at 10:53 -0400, Bill Nottingham wrote:
- If a driver is headed upstream, and is needed... just add it to the
kernel
package proper
Not just driver. We said that the kernel team could choose to include
any out of tree stuff they deem acceptable, but they would include it in
the kernel proper rather than as a nasty kernel module package hack.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
10:49 a.m.
Jesse Keating wrote:
Not just driver. We said that the kernel team could choose to
include
any out of tree stuff they deem acceptable, but they would include it in
the kernel proper rather than as a nasty kernel module package hack.
The problem is that they say "no" almost every time, even to the modules
FESCo had previously approved as kmods (em8300, sysprof). They now sit as
kmods in RPM Fusion.
Kevin Kofler
11:07 a.m.
On Fri, 2009-05-29 at 17:49 +0200, Kevin Kofler wrote:
Jesse Keating wrote:
> Not just driver. We said that the kernel team could choose to include
> any out of tree stuff they deem acceptable, but they would include it in
> the kernel proper rather than as a nasty kernel module package hack.
The problem is that they say "no" almost every time, even to the modules
FESCo had previously approved as kmods (em8300, sysprof). They now sit as
kmods in RPM Fusion.
Kevin Kofler
And as the kernel maintainers, it's their right to say no, as
particularly with the kernel any addon software can have major impact on
the entire kernel.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
9:54 a.m.
On Fri, May 29, 2009 at 4:49 PM, Richard W.M. Jones <rjones(a)redhat.com> wrote:
On Fri, May 29, 2009 at 03:33:37PM +0200, Kevin Kofler wrote:
> Josh Boyer wrote:
> > Or perhaps a future FESCo will revist kmods.
>
> FWIW, I'd certainly vote for a proposal to allow kmods if I get into FESCo
> and may even bring such a proposal in front of the new FESCo (though IMHO
> it should not be the old regime with explicit FESCo approval for each, that
> didn't make any sense, instead there should be no restrictions other than a
> license compatible with that of the kernel, and of course the restrictions
> applying to all packages).
Could someone dispassionately summarise the reasons why kmods were
rejected in the first place? Â I assume the reason was the overhead of
maintaining and updating out-of-tree kernel patches?
Because they might break on kernel updates, needs to be rebuild
everytime and in some cases require patches to work.
So we might get in a situation: pushing a kernel update will cause
broken deps for users of kmod-foo -> preventing them from installing
updates -> security risk. (outdated packages)
9:59 a.m.
On Fri, 29 May 2009, drago01 wrote:
Because they might break on kernel updates, needs to be rebuild
everytime and in some cases require patches to work.
So we might get in a situation: pushing a kernel update will cause
broken deps for users of kmod-foo -> preventing them from installing
updates -> security risk. (outdated packages)
There is no 'might' about it.
it happens.
all the time.
-sv
11:47 a.m.
On Fri, 2009-05-29 at 10:59 -0400, Seth Vidal wrote:
On Fri, 29 May 2009, drago01 wrote:
>
> Because they might break on kernel updates, needs to be rebuild
> everytime and in some cases require patches to work.
>
> So we might get in a situation: pushing a kernel update will cause
> broken deps for users of kmod-foo -> preventing them from installing
> updates -> security risk. (outdated packages)
>
There is no 'might' about it.
it happens.
all the time.
There is a solution to this particular point, which it seems many who
use kmods don't seem to know about: akmods. Install the akmod for your
kmod, and if the pre-built kmod hasn't yet been updated when a new
kernel is released, the akmod handles the problem (it gets automatically
built at boot time).
That doesn't address all the other problems, of course, which are valid.
And it doesn't help if the new kernel happens to have changed the
interface somehow so the module source doesn't build any more. But there
_is_ a solution for the "the code still builds fine but the repository
didn't update the pre-built binary yet" case. Just sayin'.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
noon
On 05/29/2009 09:47 AM, Adam Williamson wrote:
There is a solution to this particular point, which it seems many
who
use kmods don't seem to know about: akmods. Install the akmod for your
kmod, and if the pre-built kmod hasn't yet been updated when a new
kernel is released, the akmod handles the problem (it gets automatically
built at boot time).
I've used dkms (the infrastructural package is in Fedora although
there's no modules in fedora to use it). It seems similar to what you
describe.
That doesn't address all the other problems, of course, which are
valid.
And it doesn't help if the new kernel happens to have changed the
interface somehow so the module source doesn't build any more. But there
This ended up being the blocker for my personal use. For FESCo, I
remember the requirement that gcc and other build tools were needed on
an end user system was a big issue.
-Toshio
12:32 p.m.
On Fri, 2009-05-29 at 10:00 -0700, Toshio Kuratomi wrote:
On 05/29/2009 09:47 AM, Adam Williamson wrote:
> There is a solution to this particular point, which it seems many who
> use kmods don't seem to know about: akmods. Install the akmod for your
> kmod, and if the pre-built kmod hasn't yet been updated when a new
> kernel is released, the akmod handles the problem (it gets automatically
> built at boot time).
>
I've used dkms (the infrastructural package is in Fedora although
there's no modules in fedora to use it). It seems similar to what you
describe.
Yes, vanilla DKMS works like this: it doesn't use pre-built binaries at
all, it's just about wrapping the module source up into a convenient
lump and having a bit of infrastructure to automatically compile it
during startup if appropriate.
> That doesn't address all the other problems, of course,
which are valid.
> And it doesn't help if the new kernel happens to have changed the
> interface somehow so the module source doesn't build any more. But there
This ended up being the blocker for my personal use. For FESCo, I
remember the requirement that gcc and other build tools were needed on
an end user system was a big issue.
Yeah, that's the drawback to a pure source approach.
Mandriva took DKMS and hacked it up so that it creates both pre-built
binaries and 'source' packages (much like kmods and akmods in the kmod
system), so that if you have a system without the build chain things
will work as long as you're running a supported kernel and the updates
are in sync, but if you have the whole build chain, the 'source' DKMS
package covers you if you're running a different kernel or whatever. RPM
Fusion does much the same by providing both kmods and akmods.
It works for MDV but only with rather a lot of effort to ensure the
binary packages are kept in sync with kernel updates, and there were a
couple of releases where NVIDIA and ATI users suffered because this
wasn't the case, and they didn't have the kernel headers installed so
the DKMS 'source' packages didn't cover them.
NVIDIA and ATI are the major use case for MDV (and, frankly, for RPM
Fusion), so I came around to the view that it isn't really a good idea
to have kmods or DKMS in Fedora; the major use case for them doesn't
apply to Fedora and never will, and the other objections are pretty
valid for all the other cases for which DKMS / kmods can be used (either
this stuff should go straight into the kernel or we should not ship it).
And the pain involved in keeping the pre-built binaries in sync with the
kernel is significant.
On kmods vs. DKMS, I've now both built packages that use both and used
both on my own system. My perception is that DKMS is a much cleaner
system and saner to package, but kmod works slightly faster on boot. So
personally I prefer DKMS, but I may be biased (you usually prefer the
first implementation of anything you come across, as students of music
are aware :>)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
1:06 p.m.
On Fri, May 29, 2009 at 10:32:25 -0700,
Adam Williamson <awilliam(a)redhat.com> wrote:
NVIDIA and ATI are the major use case for MDV (and, frankly, for RPM
Fusion), so I came around to the view that it isn't really a good idea
to have kmods or DKMS in Fedora; the major use case for them doesn't
apply to Fedora and never will, and the other objections are pretty
valid for all the other cases for which DKMS / kmods can be used (either
this stuff should go straight into the kernel or we should not ship it).
And the pain involved in keeping the pre-built binaries in sync with the
kernel is significant.
If you use telephony hardware you also have this problem as Digium doesn't
want to upstream Dahdi / Zaptel so they can sell custom versions of
the kernel drivers under different licenses. And no one else seems to have
enough interest to fork the project and get it upstreamed. I suspect Sangoma
has similar issues, but I don't own any of their stuff.
2:09 p.m.
On Fri, 2009-05-29 at 13:06 -0500, Bruno Wolff III wrote:
On Fri, May 29, 2009 at 10:32:25 -0700,
Adam Williamson <awilliam(a)redhat.com> wrote:
>
> NVIDIA and ATI are the major use case for MDV (and, frankly, for RPM
> Fusion), so I came around to the view that it isn't really a good idea
> to have kmods or DKMS in Fedora; the major use case for them doesn't
> apply to Fedora and never will, and the other objections are pretty
> valid for all the other cases for which DKMS / kmods can be used (either
> this stuff should go straight into the kernel or we should not ship it).
> And the pain involved in keeping the pre-built binaries in sync with the
> kernel is significant.
If you use telephony hardware you also have this problem as Digium doesn't
want to upstream Dahdi / Zaptel so they can sell custom versions of
the kernel drivers under different licenses.
That is, indeed, a problem.
And no one else seems to have
enough interest to fork the project and get it upstreamed.
That would appear to be the correct solution :)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
1:47 p.m.
On Fri, May 29, 2009 at 10:32:25AM -0700, Adam Williamson wrote:
On Fri, 2009-05-29 at 10:00 -0700, Toshio Kuratomi wrote:
> On 05/29/2009 09:47 AM, Adam Williamson wrote:
>
> > There is a solution to this particular point, which it seems many who
> > use kmods don't seem to know about: akmods. Install the akmod for your
> > kmod, and if the pre-built kmod hasn't yet been updated when a new
> > kernel is released, the akmod handles the problem (it gets automatically
> > built at boot time).
> >
> I've used dkms (the infrastructural package is in Fedora although
> there's no modules in fedora to use it). It seems similar to what you
> describe.
Yes, vanilla DKMS works like this: it doesn't use pre-built binaries at
all, it's just about wrapping the module source up into a convenient
lump and having a bit of infrastructure to automatically compile it
during startup if appropriate.
If you have a package that contains pre-built binaries, DKMS will
happily use those. We use that model on the "Enterprise" distros all
the time.
> > That doesn't address all the other problems, of course,
which are valid.
> > And it doesn't help if the new kernel happens to have changed the
> > interface somehow so the module source doesn't build any more. But there
>
> This ended up being the blocker for my personal use. For FESCo, I
> remember the requirement that gcc and other build tools were needed on
> an end user system was a big issue.
Yeah, that's the drawback to a pure source approach.
Agreed.
Mandriva took DKMS and hacked it up so that it creates both
pre-built
binaries and 'source' packages (much like kmods and akmods in the kmod
system), so that if you have a system without the build chain things
will work as long as you're running a supported kernel and the updates
are in sync, but if you have the whole build chain, the 'source' DKMS
package covers you if you're running a different kernel or whatever. RPM
Fusion does much the same by providing both kmods and akmods.
I do wish MDV would send such patches upstream... I always had to go
hunting for patches.
FWIW, the Linux Foundation Driver Backport Working Group [1] has
standardized on using DKMS as a developer tool for building
[a]kmod-like packages (KMPs in Novell terminology). But of course,
that's still targeted at backporting fixes / drivers to "older"
kernels in the "stable" Enterprise distros. DKMS and related tools
really don't make sense for use as a delivery mechanism for Fedora and
other rapidly changing non-commercial-supported distributions .
Different target audience, different expected experience.
[1] http://www.linuxfoundation.org/collaborate/workgroups/driver-backport
--
Matt Domsch
Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux
1:14 p.m.
On Sat, 2009-05-30 at 13:47 -0500, Matt Domsch wrote:
> Mandriva took DKMS and hacked it up so that it creates both
pre-built
> binaries and 'source' packages (much like kmods and akmods in the kmod
> system), so that if you have a system without the build chain things
> will work as long as you're running a supported kernel and the updates
> are in sync, but if you have the whole build chain, the 'source' DKMS
> package covers you if you're running a different kernel or whatever. RPM
> Fusion does much the same by providing both kmods and akmods.
I do wish MDV would send such patches upstream... I always had to go
hunting for patches.
If they've not been, I'm not sure why; MDV usually likes upstreaming
stuff because they're extremely under-resourced when it comes to
developers, so everyone wants their life to be easier :). It may just be
that they felt the patches were sufficiently extensive/hacky that Dell
may not want them.
Anyhoo, you can find this stuff in MDV SVN:
http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/dkms/current/
A good guy to talk to about MDV's changes to DKMS would be Olivier Blin,
oblin(a)mandriva.com . I think he'd know most things you'd want to ask.
Sending off list as we appear to be somewhat off topic :)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
10:45 a.m.
drago01 wrote:
So we might get in a situation: pushing a kernel update will cause
broken deps for users of kmod-foo -> preventing them from installing
updates -> security risk. (outdated packages)
How does putting those kmods in a third-party repo fix this? And they WILL
and DO end up there. Even if you get RPM Fusion to ban kmods (which I doubt
will ever happen), they'll just migrate to another third-party repo. You
can't eliminate kmods entirely, no matter how hard you try. Having them
within Fedora would actually allow syncing the updates to kernel updates by
using a Bodhi grouped update, which would make this much less of an issue.
Kevin Kofler
10:46 a.m.
On Fri, 29 May 2009, Kevin Kofler wrote:
How does putting those kmods in a third-party repo fix this? And they
WILL
and DO end up there. Even if you get RPM Fusion to ban kmods (which I doubt
will ever happen), they'll just migrate to another third-party repo. You
can't eliminate kmods entirely, no matter how hard you try.
I don't know about that - let's try harder and see if we can. :)
-sv
10:57 a.m.
> How does putting those kmods in a third-party repo fix this? And
they WILL
> and DO end up there. Even if you get RPM Fusion to ban kmods (which I
> doubt
> will ever happen), they'll just migrate to another third-party repo. You
> can't eliminate kmods entirely, no matter how hard you try.
kmod-gspca has been available in livna for a long time. And I loved
it, as it provided me an easy way to use my webcam.
But at every kernel update, it was a PITA to wait for the kmod until I
could update the kernel.
If Fedora had accepted the kmod in its repositories, would it have
ever been included in mainstream kernel as it is today (which is the
only real solution) ?
By refusing kmods, we have more motivation to actually try and include
upstream what we really need to use. If we can simply install the
kmod, who cares if it's upstreamed ?
----------
Mathieu Bridon (bochecha)
11:52 a.m.
On 05/29/2009 09:27 PM, Mathieu Bridon (bochecha) wrote:
By refusing kmods, we have more motivation to actually try and include
upstream what we really need to use. If we can simply install the
kmod, who cares if it's upstreamed ?
We generally do care about whether something is upstream or not for
various reasons discussed many times here but also because we push out
new kernel updates often within a particular release and that has a good
chance of breaking out of tree modules. End users do care about that as
well.
Rahul
3:54 p.m.
On Fri, May 29, 2009 at 5:57 PM, Mathieu Bridon (bochecha)
<bochecha(a)fedoraproject.org> wrote:
>> How does putting those kmods in a third-party repo fix this?
And they WILL
>> and DO end up there. Even if you get RPM Fusion to ban kmods (which I
>> doubt
>> will ever happen), they'll just migrate to another third-party repo. You
>> can't eliminate kmods entirely, no matter how hard you try.
kmod-gspca has been available in livna for a long time. And I loved
it, as it provided me an easy way to use my webcam.
But at every kernel update, it was a PITA to wait for the kmod until I
could update the kernel.
If Fedora had accepted the kmod in its repositories, would it have
ever been included in mainstream kernel as it is today (which is the
only real solution) ?
By refusing kmods, we have more motivation to actually try and include
upstream what we really need to use. If we can simply install the
kmod, who cares if it's upstreamed ?
This particular one _IS_ upstreamed. It was merged upstream in 2.6.28.
2.6.29.4 is in F10 updates-testing and F11 will ship with a .29 based
kernel anyway.
So you don't really need it anymore ;)
4:08 p.m.
On Fri, 2009-05-29 at 22:54 +0200, drago01 wrote:
> kmod-gspca has been available in livna for a long time. And I
loved
> it, as it provided me an easy way to use my webcam.
>
> But at every kernel update, it was a PITA to wait for the kmod until I
> could update the kernel.
>
> If Fedora had accepted the kmod in its repositories, would it have
> ever been included in mainstream kernel as it is today (which is the
> only real solution) ?
>
> By refusing kmods, we have more motivation to actually try and include
> upstream what we really need to use. If we can simply install the
> kmod, who cares if it's upstreamed ?
This particular one _IS_ upstreamed. It was merged upstream in 2.6.28.
2.6.29.4 is in F10 updates-testing and F11 will ship with a .29 based
kernel anyway.
So you don't really need it anymore ;)
That was his point. He was saying that, if kmods were accepted in
Fedora, Fedora developers and users may not have done the work /
provided the pressure for it to be upstreamed.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
10:53 a.m.
On Fri, May 29, 2009 at 05:45:18PM +0200, Kevin Kofler wrote:
drago01 wrote:
> So we might get in a situation: pushing a kernel update will cause
> broken deps for users of kmod-foo -> preventing them from installing
> updates -> security risk. (outdated packages)
How does putting those kmods in a third-party repo fix this? And they WILL
and DO end up there. Even if you get RPM Fusion to ban kmods (which I doubt
will ever happen), they'll just migrate to another third-party repo. You
can't eliminate kmods entirely, no matter how hard you try. Having them
within Fedora would actually allow syncing the updates to kernel updates by
using a Bodhi grouped update, which would make this much less of an issue.
I am respectfully requesting that you start an entirely new mail thread if you
really want to continue this discussion.
josh
9:58 a.m.
On Fri, 29 May 2009, Richard W.M. Jones wrote:
On Fri, May 29, 2009 at 03:33:37PM +0200, Kevin Kofler wrote:
> Josh Boyer wrote:
>> Or perhaps a future FESCo will revist kmods.
>
> FWIW, I'd certainly vote for a proposal to allow kmods if I get into FESCo
> and may even bring such a proposal in front of the new FESCo (though IMHO
> it should not be the old regime with explicit FESCo approval for each, that
> didn't make any sense, instead there should be no restrictions other than a
> license compatible with that of the kernel, and of course the restrictions
> applying to all packages).
Could someone dispassionately summarise the reasons why kmods were
rejected in the first place? I assume the reason was the overhead of
maintaining and updating out-of-tree kernel patches?
1. out-of-tree kernel modules should not be encouraged - if it can't be in
the upstream kernel then why are we including it in fedora?
2. the behavior for multiply-installed kernels and kernel modules with
updates is not-wonderful
3. kernels being released into a repo and the kernel-modules not being
caught up plays hell w/proper updates
-sv
5436
days inactive
5440
days old
38 comments
21 participants
participants (21)
-
Adam Williamson -
Bill Nottingham -
Bruno Wolff III -
drago01 -
Jesse Keating -
John Poelstra -
Jon Stanley -
Josh Boyer -
Kevin Kofler -
Matej Cepl -
Mathieu Bridon -
Matt Domsch -
Matthew Garrett -
Orcan Ogetbil -
Rahul Sundaram -
Richard W.M. Jones -
Seth Vidal -
Susi Lehtola -
Thorsten Leemhuis -
Till Maas -
Toshio Kuratomi