Re: kernel versioning

2006-03-12 Thread Paul Wouters
On Sun, 12 Mar 2006, Arjan van de Ven wrote: > well API changes are one of the prices you pay for being an outside > module, and is not unique to Fedora. > > The entire kernel development model is setup for having everything in > one repo, and everything outside that is just painful. See that as >

Re: kernel versioning

2006-03-12 Thread Arjan van de Ven
> HAVE_SOCK_ZAPPED > NET_26_12_SKALLOC > HAVE_SOCK_SECURITY > HAVE_SKB_NF_DEBUG > SYSCTL_IPSEC_DEFAULT_TTL > HAVE_TSTAMP > HAVE_INET_SK_SPORT > > Unfortunately, I really have no idea how to better do this, unless fedora > ships some kernel header so at least all software projects could just > re-

Re: kernel versioning

2006-03-11 Thread Paul Wouters
On Sat, 11 Mar 2006, dragoran wrote: > > > Any thoughts on how to make everyone happy? :) > > > > I have no idea :( > > > > Paul > > > A solution is not to check the kernel version but to check for features/apis > they need. > the (closed) nvidia driver does this for the wrapper part and it seems

Re: kernel versioning

2006-03-11 Thread dragoran
Paul Wouters wrote: On Fri, 10 Mar 2006, Axel Thimm wrote: upstream kernels that are release candidates or git sub-rcs etc. are versioned in FC/RHEL based on the previous stable kernel release, e.g. FC5's 2.6.16-rc5-git9 kernel is released as 2.6.15. I generally think that's a good idea (e

ÂRe: kernel versioning

2006-03-10 Thread Paul Wouters
On Fri, 10 Mar 2006, Axel Thimm wrote: > upstream kernels that are release candidates or git sub-rcs etc. are > versioned in FC/RHEL based on the previous stable kernel release, > e.g. FC5's 2.6.16-rc5-git9 kernel is released as 2.6.15. > > I generally think that's a good idea (e.g. it *is* 2.6.15

Re: kernel versioning

2006-03-10 Thread Leszek Matok
Dnia 10-03-2006, pią o godzinie 09:44 +0100, Axel Thimm napisał(a): > But tons of kernel module projects check on the version of the kernel > and trigger different code bits. These projects depend on the > versioning to decide whether some features exist or not. 2.6.17-pre1 will have SUBLEVEL=17 an

Re: kernel versioning

2006-03-10 Thread Axel Thimm
On Fri, Mar 10, 2006 at 11:12:42AM +0100, Arjan van de Ven wrote: > On Fri, 2006-03-10 at 09:44 +0100, Axel Thimm wrote: > > Hi, > > > > upstream kernels that are release candidates or git sub-rcs etc. are > > versioned in FC/RHEL based on the previous stable kernel release, > > e.g. FC5's 2.6.16-

Re: kernel versioning

2006-03-10 Thread Arjan van de Ven
On Fri, 2006-03-10 at 09:44 +0100, Axel Thimm wrote: > Hi, > > upstream kernels that are release candidates or git sub-rcs etc. are > versioned in FC/RHEL based on the previous stable kernel release, > e.g. FC5's 2.6.16-rc5-git9 kernel is released as 2.6.15. > > I generally think that's a good id

kernel versioning

2006-03-10 Thread Axel Thimm
Hi, upstream kernels that are release candidates or git sub-rcs etc. are versioned in FC/RHEL based on the previous stable kernel release, e.g. FC5's 2.6.16-rc5-git9 kernel is released as 2.6.15. I generally think that's a good idea (e.g. it *is* 2.6.15 with patches towards 2.6.16 and not yet 2.6