Hi,
Currently each Rawhide pre-release kernel reports as its version number the version number of the previous stable version, rather than the current version.
This sometimes causes problems with out-of-kernel modules (e.g. with madwifi), since the exposed kernel API has changed and the #ifdef's normally checks for the new version.
Since the typical end-user on a stable Fedora release will never see these pre-release kernels, what would be the downside of, say, calling the current kernel 2.6.21-0.2997.fc7 rather than 2.6.20-1.2997.fc7 ?
Thanks,
2007/3/18, Michel Salim michel.salim@gmail.com:
Hi,
Currently each Rawhide pre-release kernel reports as its version number the version number of the previous stable version, rather than the current version.
This sometimes causes problems with out-of-kernel modules (e.g. with madwifi), since the exposed kernel API has changed and the #ifdef's normally checks for the new version.
Since the typical end-user on a stable Fedora release will never see these pre-release kernels, what would be the downside of, say, calling the current kernel 2.6.21-0.2997.fc7 rather than 2.6.20-1.2997.fc7 ?
Thanks,
-- Michel Salim http://hircus.wordpress.com/
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Well, i have the same problem some time ago with rt2x00 Ralink chipsets (when it was not inside the kernel, mean since 2.6.21rc1 ) I try to build some kmod (review was here : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=202528 - This is planned to be closed when 2.6.21 will be stable...) It was working fine with each 2.6.19 release but not for 2.6.20-1.2925.fc6 See here: http://rt2x00.serialmonkey.com/phpBB2/viewtopic.php?p=20463#20463 There is a problem with the rfkill part...I din't dig more for now... I'm surprised that another driver have the same issue, i've thought this was happenning only with rt2x00. Developpers of this module don't support fedora build error for this reason...
Nicolas (kwizart)
2007/3/18, KH KH kwizart@gmail.com:
Well, i have the same problem some time ago with rt2x00 Ralink chipsets (when it was not inside the kernel, mean since 2.6.21rc1 ) I try to build some kmod (review was here : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=202528 - This is planned to be closed when 2.6.21 will be stable...) It was working fine with each 2.6.19 release but not for 2.6.20-1.2925.fc6 See here: http://rt2x00.serialmonkey.com/phpBB2/viewtopic.php?p=20463#20463 There is a problem with the rfkill part...I din't dig more for now... I'm surprised that another driver have the same issue, i've thought this was happenning only with rt2x00. Developpers of this module don't support fedora build error for this reason...
Generally the fix is quite trivial: if the kernel module supports several different kernels, find the place where it probes what kernel it's being built against and change references to the upstream kernel version (in this case 2.6.21) to 2.6.20, which is what your kernel is reporting.
It's just a bit annoying to have to do it each time, since I'd have to delete the modified file everytime it's modified upstream, get the newer version and then re-modify it.
Regards,
On Sun, 2007-03-18 at 18:00 -0400, Michel Salim wrote:
Currently each Rawhide pre-release kernel reports as its version number the version number of the previous stable version, rather than the current version.
This sometimes causes problems with out-of-kernel modules
I stopped caring here.
Either way, you're shipping something which is neither 2.6.20 nor 2.6.21, and in fact isn't even a point between them; we have patches of our own. Neither version is 'correct'.
On 19.03.2007 08:19, David Woodhouse wrote:
On Sun, 2007-03-18 at 18:00 -0400, Michel Salim wrote:
Currently each Rawhide pre-release kernel reports as its version number the version number of the previous stable version, rather than the current version. This sometimes causes problems with out-of-kernel modules
I stopped caring here. [...]
@davej: This issue was discussed on FudCON Boston. Didn't you indicate you might want to change it, so that a 2.6.foo-rc kernel actually gets the proper version (e.g. 2.6.foo and not 2.6.(foo-1) )? Or did I got you wrong here?
CU thl (who really hates this version games, as it confused users a whole lot and breaks external modules for no good reasons afaics)
On Mon, Mar 19, 2007 at 08:50:12AM +0100, Thorsten Leemhuis wrote:
On 19.03.2007 08:19, David Woodhouse wrote:
On Sun, 2007-03-18 at 18:00 -0400, Michel Salim wrote:
Currently each Rawhide pre-release kernel reports as its version number the version number of the previous stable version, rather than the current version. This sometimes causes problems with out-of-kernel modules
I stopped caring here. [...]
@davej: This issue was discussed on FudCON Boston. Didn't you indicate you might want to change it, so that a 2.6.foo-rc kernel actually gets the proper version (e.g. 2.6.foo and not 2.6.(foo-1) )? Or did I got you wrong here?
We could add the 'real' upstream version in brackets in the uname field so it shows up as ..
uname -r 2.6.20-1.2925.fc6debug (2.6.20.3)
for eg.
Dave
Le Lun 19 mars 2007 17:23, Dave Jones a écrit :
Hi Dave,
We could add the 'real' upstream version in brackets in the uname field so it shows up as ..
uname -r 2.6.20-1.2925.fc6debug (2.6.20.3)
Are you violently opposed to 2.6.20.3-1.2925.fc7 for a 2.6.20.3 based kernel
and
2.6.21-0.2925.rc4.f7 for a 2.6.21-rc4 based kernel
That would make many people happy
On Mon, Mar 19, 2007 at 05:30:40PM +0100, Nicolas Mailhot wrote:
Le Lun 19 mars 2007 17:23, Dave Jones a écrit :
We could add the 'real' upstream version in brackets in the uname field so it shows up as ..
uname -r 2.6.20-1.2925.fc6debug (2.6.20.3)
Are you violently opposed to 2.6.20.3-1.2925.fc7 for a 2.6.20.3 based kernel
and
2.6.21-0.2925.rc4.f7 for a 2.6.21-rc4 based kernel
That would make many people happy
Nicolas += 1000; :)
(and nice-to-have: Instead of 1.2925 why not a simple integer? E.g. 2.6.20.3-1.fc7)
On 3/19/07, Jesse Keating jkeating@redhat.com wrote:
On Monday 19 March 2007 16:28:06 Axel Thimm wrote:
Instead of 1.2925 why not a simple integer?
2925 is generated from the cvs checkin ID. No need to worry about it ever, cvs IDs are always incrementing.
cvs ? working on kernel at RH has to be really... interesting ;)
anyway, I'm glad to finally know where that "magic" number come from
On 3/19/07, Jesse Keating jkeating@redhat.com wrote:
On Monday 19 March 2007 16:46:15 Gianluca Sforna wrote:
cvs ? working on kernel at RH has to be really... interesting ;)
All the specs for every package is in CVS.
ahh the specs. For a minute I thought it could be the sources...
On Monday 19 March 2007 17:02:51 Gianluca Sforna wrote:
ahh the specs. For a minute I thought it could be the sources...
Well, it is. The sources that don't come in the upstream tarball that is. Now granted, one could mange all of it in a different SCM, generate a srpm from that scm, import it into the package CVS and clobber whatever was there first, but meh...
Le lundi 19 mars 2007 à 16:33 -0400, Jesse Keating a écrit :
On Monday 19 March 2007 16:28:06 Axel Thimm wrote:
Instead of 1.2925 why not a simple integer?
2925 is generated from the cvs checkin ID. No need to worry about it ever, cvs IDs are always incrementing.
You have to wonder why davej is bothering with versionning at all. He could use the cvs ID as epoch, that would only be slightly more horrible.
<runs/>
On Mon, Mar 19, 2007 at 04:33:22PM -0400, Jesse Keating wrote:
On Monday 19 March 2007 16:28:06 Axel Thimm wrote:
Instead of 1.2925 why not a simple integer?
2925 is generated from the cvs checkin ID.
Yes, I know, but why do we need to know that on the user level? :=)
We don't have this convenience setup in other packages, although nothing stops a package to use the same embed-the-CVS-id-and-never- bump-the-release-tag-ever method.
No need to worry about it ever, cvs IDs are always incrementing.
Given that we'd like to rethink whether CVS can finally rip, that it is not really needed anyway in the release tag, maybe it would be good to cast it away, too.
But the may part is getting %version right, everything else is just cosmetics.
-
Axel Thimm -
Dave Jones -
David Woodhouse -
Gianluca Sforna -
Jesse Keating -
Michel Salim -
Nicolas Chauvet -
Nicolas Mailhot -
Thorsten Leemhuis