I hope a kernel developer can jump on here, but...
Is it possible that we will see this new kernel for F7, F8 and F9? I'm sure F9 will have it, per the ones you've been running for Koji, but what about these? I'd love to see one for F7, but I'm thinking it is so late in the support period that this may not happen.
Thoughts? Concerns? Utter chaos and panic? :-)
******************************************************************************* Gilbert Sebenste ******** (My opinions only!) ****** *******************************************************************************
On Fri, 2008-01-25 at 09:52 -0600, Gilbert Sebenste wrote:
I hope a kernel developer can jump on here, but...
Is it possible that we will see this new kernel for F7, F8 and F9? I'm sure F9 will have it, per the ones you've been running for Koji, but what about these? I'd love to see one for F7, but I'm thinking it is so late in the support period that this may not happen.
Thoughts? Concerns? Utter chaos and panic? :-)
I thought things never get backported for Fedora kernels, but the kernels get rebased to what is current stable when a need to do an update arises (possible a security flaw or something). I do not know whether it is a documented policy though.
On the other side the version number is no reason to do an update. And you mentioned no fixes or enhancements that do you consider important other that the version number. If there are some, I think filing a report in Bugzilla won't hurt.
Thanks,
On Fri, 25 Jan 2008, Lubomir Kundrak wrote:
And you mentioned no fixes or enhancements that do you consider important other that the version number. If there are some, I think filing a report in Bugzilla won't hurt.
I thought for just general improvements and wireless fixes this would be a great thing to do. I just file bz #430260; anyone else who has specific items, please comment on there.
******************************************************************************* Gilbert Sebenste ******** (My opinions only!) ****** *******************************************************************************
On Jan 25, 2008 5:01 PM, Lubomir Kundrak lkundrak@redhat.com wrote:
On Fri, 2008-01-25 at 09:52 -0600, Gilbert Sebenste wrote:
I hope a kernel developer can jump on here, but...
Is it possible that we will see this new kernel for F7, F8 and F9? I'm sure F9 will have it, per the ones you've been running for Koji, but what about these? I'd love to see one for F7, but I'm thinking it is so late in the support period that this may not happen.
Thoughts? Concerns? Utter chaos and panic? :-)
I thought things never get backported for Fedora kernels, but the kernels get rebased to what is current stable when a need to do an update arises (possible a security flaw or something). I do not know whether it is a documented policy though.
On the other side the version number is no reason to do an update. And you mentioned no fixes or enhancements that do you consider important other that the version number. If there are some, I think filing a report in Bugzilla won't hurt.
In fedora kernels always got rebased to 2.6.x+1 after a bit of testing I don't see any reason why this should change now. This way we get upstream improvements (new/better hardware support) and bugfixes without having to wait/update to the the next release.
On Fri, 25 Jan 2008, drago01 wrote:
In fedora kernels always got rebased to 2.6.x+1 after a bit of testing I don't see any reason why this should change now. This way we get upstream improvements (new/better hardware support) and bugfixes without having to wait/update to the the next release.
I'm all for that. :-) As a courtesy, I did file an official bugzilla. Also, Koji has been acting weird over the last day. Some stuff hasn't been building, and the web site was down for a time last night.
******************************************************************************* Gilbert Sebenste ******** (My opinions only!) ****** *******************************************************************************
On Jan 25, 2008 2:14 PM, Gilbert Sebenste sebenste@weather.admin.niu.edu wrote:
Also, Koji has been acting weird over the last day. Some stuff hasn't been building, and the web site was down for a time last night.
There was a planned Koji outage last night in order to upgrade the storage.
drago01 wrote:
On Jan 25, 2008 5:01 PM, Lubomir Kundrak lkundrak@redhat.com wrote:
On Fri, 2008-01-25 at 09:52 -0600, Gilbert Sebenste wrote:
In fedora kernels always got rebased to 2.6.x+1 after a bit of testing I don't see any reason why this should change now. This way we get upstream improvements (new/better hardware support) and bugfixes without having to wait/update to the the next release.
I like the older releases keeping the older versions. I have to run the older version because of a network lockup which rawhide kernels exhibit. kernel-2.6.23.14-107.fc8 works fine at .23 kernel-2.6.24-0.167.rc8.git4.fc9 introduces bugs in .24
I'd rather have newer programs and a stabilized kernel. The drivers that I need are available and work excellent before .24 introduced bugs. Openoffice.org for rawhide loads quicker and works without problems. Advancements in programs is more important to me than adding and deleting support for kernel level devices.
fc9 kernels hang at 1161 ? D< 0:00 /sbin/modprobe pcmcia:m015Fc000Af06fn00pfn00paA17C320Epb3D011600pc00000000pd00000000
Whatever that is.
Jim
On 01/25/2008 07:11 PM, Jim Cornette wrote:
drago01 wrote:
On Jan 25, 2008 5:01 PM, Lubomir Kundrak lkundrak@redhat.com wrote:
On Fri, 2008-01-25 at 09:52 -0600, Gilbert Sebenste wrote:
In fedora kernels always got rebased to 2.6.x+1 after a bit of testing I don't see any reason why this should change now. This way we get upstream improvements (new/better hardware support) and bugfixes without having to wait/update to the the next release.
I like the older releases keeping the older versions. I have to run the older version because of a network lockup which rawhide kernels exhibit. kernel-2.6.23.14-107.fc8 works fine at .23 kernel-2.6.24-0.167.rc8.git4.fc9 introduces bugs in .24
I'd rather have newer programs and a stabilized kernel. The drivers that I need are available and work excellent before .24 introduced bugs. Openoffice.org for rawhide loads quicker and works without problems. Advancements in programs is more important to me than adding and deleting support for kernel level devices.
fc9 kernels hang at 1161 ? D< 0:00 /sbin/modprobe pcmcia:m015Fc000Af06fn00pfn00paA17C320Epb3D011600pc00000000pd00000000
Whatever that is.
It's loading the driver for a Cisco Aironet wireless PCMCIA adapter.
Chuck Ebbert wrote:
On 01/25/2008 07:11 PM, Jim Cornette wrote:
drago01 wrote:
On Jan 25, 2008 5:01 PM, Lubomir Kundrak lkundrak@redhat.com wrote:
On Fri, 2008-01-25 at 09:52 -0600, Gilbert Sebenste wrote:
In fedora kernels always got rebased to 2.6.x+1 after a bit of testing I don't see any reason why this should change now. This way we get upstream improvements (new/better hardware support) and bugfixes without having to wait/update to the the next release.
I like the older releases keeping the older versions. I have to run the older version because of a network lockup which rawhide kernels exhibit. kernel-2.6.23.14-107.fc8 works fine at .23 kernel-2.6.24-0.167.rc8.git4.fc9 introduces bugs in .24
I'd rather have newer programs and a stabilized kernel. The drivers that I need are available and work excellent before .24 introduced bugs. Openoffice.org for rawhide loads quicker and works without problems. Advancements in programs is more important to me than adding and deleting support for kernel level devices.
fc9 kernels hang at 1161 ? D< 0:00 /sbin/modprobe pcmcia:m015Fc000Af06fn00pfn00paA17C320Epb3D011600pc00000000pd00000000
Whatever that is.
It's loading the driver for a Cisco Aironet wireless PCMCIA adapter.
Thanks Chuck! I have a bug report filed regarding this error https://bugzilla.redhat.com/show_bug.cgi?id=426714
My network does not hang with the .23 version but it does with the .24 version. It appears that the wireless is being identified as eth0 for the fc9 version but is eth1 for the fc8 version.
Still upgrading Fedora 8 to .24 versions would disadvantage me for now.
Jim
Jim Cornette wrote:
drago01 wrote:
I like the older releases keeping the older versions. I have to run the older version because of a network lockup which rawhide kernels exhibit.
If you want that kind of stability, you can have it with CentOS.
John Summerfield wrote:
Jim Cornette wrote:
drago01 wrote:
I like the older releases keeping the older versions. I have to run the older version because of a network lockup which rawhide kernels exhibit.
If you want that kind of stability, you can have it with CentOS.
If you reference versions as snapshots of current development with limited support life cycles, it would disadvantage people who decided to stay back in the earlier snapshots. It distracts productive time from developers in my opinion to have to provide parallel support for different timestamped versions which will reach end of life shortly. Only security updates should be offered for the earlier versions. An exception would be for removing and closing an open bug ticket for a problem that is not fixed until a later version which requires no excessive amount of work for the developer in order to make a version for the older release. If it is relatively certain that no bugs will be introduced when the kernel is upgraded on older versions, go ahead and provide an update. I have a problem with hardware breakage for updated versions of a kernel. Others are bound to have similar problems. For Fedora 7, aren't the devices called /dev/hdx still? Wouldn't that cause a lot of grief for Fedora 7 users?
Just my view. I'll know to stay back to a .23 if Fedora 8 goes to the .24 version for now.
In my view, Jim
Jim Cornette wrote:
John Summerfield wrote:
Jim Cornette wrote:
drago01 wrote:
I like the older releases keeping the older versions. I have to run the older version because of a network lockup which rawhide kernels exhibit.
If you want that kind of stability, you can have it with CentOS.
If you reference versions as snapshots of current development with limited support life cycles, it would disadvantage people who decided to stay back in the earlier snapshots. It distracts productive time from developers in my opinion to have to provide parallel support for different timestamped versions which will reach end of life shortly. Only security updates should be offered for the earlier versions. An exception would be for removing and closing an open bug ticket for a problem that is not fixed until a later version which requires no excessive amount of work for the developer in order to make a version for the older release. If it is relatively certain that no bugs will be introduced when the kernel is upgraded on older versions, go ahead and provide an update. I have a problem with hardware breakage for updated versions of a kernel. Others are bound to have similar problems. For Fedora 7, aren't the devices called /dev/hdx still? Wouldn't that cause a lot of grief for Fedora 7 users?
Just my view. I'll know to stay back to a .23 if Fedora 8 goes to the .24 version for now.
It's your choice, but if you regard Fedora as a rolling beta you're be close to the mark.
Red Hat gets to test and evaluate (users responses to) new technology. Technology tested here may make its way into RHEL. An old kernel will never get into RHEL, so once there's a new kernel there's no point for RH to support supporting an old kernel.
If you want to carry that load fine, but from what I've seen RH carries the Fedora kernel.
Think, if you had a financial interest in where Fedora goes - say you were basing your own distro and support from Fedora's progress, and you decided to hire a few people to work on it.
Would those workers work on parts of no significance to you? _I_'d identify technologies key to what _I_ want and point them at those. Maybe the KDE desktop and KDE applications.
Jim Cornette wrote:
drago01 wrote:
On Jan 25, 2008 5:01 PM, Lubomir Kundrak lkundrak@redhat.com wrote:
On Fri, 2008-01-25 at 09:52 -0600, Gilbert Sebenste wrote:
In fedora kernels always got rebased to 2.6.x+1 after a bit of testing I don't see any reason why this should change now. This way we get upstream improvements (new/better hardware support) and bugfixes without having to wait/update to the the next release.
I like the older releases keeping the older versions. I have to run the older version because of a network lockup which rawhide kernels exhibit. kernel-2.6.23.14-107.fc8 works fine at .23 kernel-2.6.24-0.167.rc8.git4.fc9 introduces bugs in .24
I'd rather have newer programs and a stabilized kernel. The drivers that I need are available and work excellent before .24 introduced bugs. Openoffice.org for rawhide loads quicker and works without problems. Advancements in programs is more important to me than adding and deleting support for kernel level devices.
fc9 kernels hang at 1161 ? D< 0:00 /sbin/modprobe pcmcia:m015Fc000Af06fn00pfn00paA17C320Epb3D011600pc00000000pd00000000
Whatever that is.
Jim
You know, there is nothing holding you back from not updating kernels, even if .24 versions are backported and pushed out for f7/f8. The kernels that have been built before it are available, and should continue to be until EOL (well, forever actually if you just keep a copy for yourself).
Andrew Farris wrote:
You know, there is nothing holding you back from not updating kernels, even if .24 versions are backported and pushed out for f7/f8. The kernels that have been built before it are available, and should continue to be until EOL (well, forever actually if you just keep a copy for yourself).
Right now I let yum keep just the two kernel entries and hopefully am not running the fc9 version while running yum. I periodically grab the latest version of a Fedora 8 version of the kernel to ensure relative advancements and security patches are applied. If the version was upgraded to .24 instead of maintaining the currently available .23 version I would loose out on bug fixes and security fixes unless I personally back ported the fixes. Also there is nothing preventing someone from running an f9 kernel on an earlier version operating system. I realize nash and mkinitrd might need upgraded also for proper kernel installation. It doesn't make sense to me to hold off on application improvements and only want newer based kernels. I see that these type of individuals exist so I'll live with the different philosophical differences in approach to kernel and applications.
Jim
Jim Cornette <fct-cornette <at> insight.rr.com> writes:
It doesn't make sense to me to hold off on application improvements and only want newer based kernels. I see that these type of individuals exist so I'll live with the different philosophical differences in approach to kernel and applications.
That's why application updates are also pushed to stable Fedora releases where it makes sense. :-)
For example, we're always pushing bugfix releases of KDE (x.y.z -> x.y.z+1), and we (well, Than Ngo, and Rex Dieter independently in his kde-redhat repository, as this was before the Core-Extras merge) already pushed a x.y.z->x.y+1.0 update once (3.4.x->3.5.0 in FC4) and we plan to do that again in Fedora 9 (4.0.x->4.1.0). What we _don't_ push is x.y.z->x+1.0.0 updates (thinking in terms of the kernel, that would be like updating a distro which shipped with 2.4 to 2.6), if you want KDE 4 for Fedora 8, you can get it from the kde-redhat unstable repository. (Note that the packages in kde-redhat unstable are rebuilds of the packages we're working on in Rawhide, there aren't separate "official Fedora" and "kde-redhat" flavors of KDE anymore. We're also using kde-redhat-devel as our SIG mailing list these days.)
Kevin Kofler
On Fri, 25 Jan 2008 09:52:59 -0600, Gilbert Sebenste scripst:
I hope a kernel developer can jump on here, but...
Is it possible that we will see this new kernel for F7, F8 and F9? I'm sure F9 will have it, per the ones you've been running for Koji, but what about these? I'd love to see one for F7, but I'm thinking it is so late in the support period that this may not happen.
Thoughts? Concerns? Utter chaos and panic? :-)
*******************************************************************************
Gilbert Sebenste ******** (My opinions only!) ******
*******************************************************************************
curl -O http://people.redhat.com/davej/kernels/Fedora/fc7/kernel.repo mv kernel.repo /etc/yum.repos.d/ yum upgrade