[opensuse-kernel] time to branch 10.3 kernel tree?
As 2.6.23 is now out, should we branch the 10.3 kernel tree from HEAD now? I think I'll be doing at least one more 2.6.22-stable release, which we should probably apply to the 10.3 kernel and push that out when it happens, but we should also work on moving on to 2.6.23. Any thoughts? thanks, greg k-h -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greg KH wrote:
As 2.6.23 is now out, should we branch the 10.3 kernel tree from HEAD now? I think I'll be doing at least one more 2.6.22-stable release, which we should probably apply to the 10.3 kernel and push that out when it happens, but we should also work on moving on to 2.6.23.
Any thoughts?
Absolutely. I was going to branch it this week and try merging 2.6.23. I'd like to try to keep HEAD following mainline as closely as possible, even with no pending release. At the very least, it would be useful for handling bug reports so we can see if a particular bug has been solved in the next kernel cycle. - -Jeff (Sorry for the resend, Greg. The list wanted my @suse.com address.) - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD4DBQFHDRzTLPWxlyuTD7IRAsL1AJil4GmkCN3EY/OsoYu8qCb5f0hfAJ4gvMYq aMS5fpwji6djgWqaegFTpQ== =Z+1F -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Wed, Oct 10, 2007 at 02:41:23PM -0400, Jeff Mahoney wrote:
Greg KH wrote:
As 2.6.23 is now out, should we branch the 10.3 kernel tree from HEAD now? I think I'll be doing at least one more 2.6.22-stable release, which we should probably apply to the 10.3 kernel and push that out when it happens, but we should also work on moving on to 2.6.23.
Any thoughts?
Absolutely. I was going to branch it this week and try merging 2.6.23. I'd like to try to keep HEAD following mainline as closely as possible, even with no pending release. At the very least, it would be useful for handling bug reports so we can see if a particular bug has been solved in the next kernel cycle.
Ok, that sounds fine with me, I'll wait and let you do the branch :) thanks, greg k-h -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
Jeff Mahoney <jeffm@suse.com> writes:
Greg KH wrote:
As 2.6.23 is now out, should we branch the 10.3 kernel tree from HEAD now? I think I'll be doing at least one more 2.6.22-stable release, which we should probably apply to the 10.3 kernel and push that out when it happens, but we should also work on moving on to 2.6.23.
Any thoughts?
Absolutely. I was going to branch it this week and try merging 2.6.23. I'd like to try to keep HEAD following mainline as closely as possible, even with no pending release. At the very least, it would be useful for handling bug reports so we can see if a particular bug has been solved in the next kernel cycle.
Jeff, could you rename also kernel-bigsmp to "kernel-pae", please? Thanks, Andreas -- Andreas Jaeger, Director Platform/openSUSE, aj@suse.de SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
On Oct 12 2007 17:09, Andreas Jaeger wrote:
Greg KH wrote:
As 2.6.23 is now out, should we branch the 10.3 kernel tree from HEAD now? I think I'll be doing at least one more 2.6.22-stable release, which we should probably apply to the 10.3 kernel and push that out when it happens, but we should also work on moving on to 2.6.23.
Any thoughts?
Absolutely. I was going to branch it this week and try merging 2.6.23. I'd like to try to keep HEAD following mainline as closely as possible, even with no pending release. At the very least, it would be useful for handling bug reports so we can see if a particular bug has been solved in the next kernel cycle.
Jeff, could you rename also kernel-bigsmp to "kernel-pae", please?
It is not just a PAEd kernel, but also allows for a higher number of CPUs. That is the "big" in bigsmp. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
Jan Engelhardt <jengelh@computergmbh.de> writes:
On Oct 12 2007 17:09, Andreas Jaeger wrote:
Greg KH wrote:
As 2.6.23 is now out, should we branch the 10.3 kernel tree from HEAD now? I think I'll be doing at least one more 2.6.22-stable release, which we should probably apply to the 10.3 kernel and push that out when it happens, but we should also work on moving on to 2.6.23.
Any thoughts?
Absolutely. I was going to branch it this week and try merging 2.6.23. I'd like to try to keep HEAD following mainline as closely as possible, even with no pending release. At the very least, it would be useful for handling bug reports so we can see if a particular bug has been solved in the next kernel cycle.
Jeff, could you rename also kernel-bigsmp to "kernel-pae", please?
It is not just a PAEd kernel, but also allows for a higher number of CPUs. That is the "big" in bigsmp.
I do know exactly this. We want to install this kernel by default on i386 since it allows us to use non-executable stack etc (a PAE feature). We tried with 10.3 but many user complained why their 1GB machine got a bigsmp kernel. And therefore my suggestion to change it, Andreas -- Andreas Jaeger, Director Platform / openSUSE, aj@suse.de SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
On Oct 12 2007 17:36, Andreas Jaeger wrote:
Jeff, could you rename also kernel-bigsmp to "kernel-pae", please?
It is not just a PAEd kernel, but also allows for a higher number of CPUs. That is the "big" in bigsmp.
I do know exactly this. We want to install this kernel by default on i386 since it allows us to use non-executable stack etc (a PAE feature).
Does PAE incur a performance hit, even if the total amount of memory is less than 4GB? By default? By default I get default, not bigsmp (or pae, FWIW).
We tried with 10.3 but many user complained why their 1GB machine got a bigsmp kernel.
And therefore my suggestion to change it,
So the name change is because they complained they got a bigsmp? (That's how I read it.) I'd say they complained because they got a bigsmp/pae in the first place (but you may prove me wrong with a BZ entry). -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Fri, 12 Oct 2007, Jan Engelhardt wrote:
We tried with 10.3 but many user complained why their 1GB machine got a bigsmp kernel.
And therefore my suggestion to change it,
So the name change is because they complained they got a bigsmp? (That's how I read it.) I'd say they complained because they got a bigsmp/pae in the first place (but you may prove me wrong with a BZ entry).
well, the question is did people complain because of the name "bigsmp" or have there been real "functional" problems ? - drivers not available for bigsmp/pae - software not working with it (AFAIR vmware has been fixed) - functionality not working: suspend as most important feature Note, I'm not saying any of these don't work, I'm rather asking if they all do ? And wasn't there the story that bigsmp also uses a different memory layout (kernel/userspace split). Are there any drawbacks to that setup ? -- with kind regards (mit freundlichem Grinsen), Ruediger Oertel (ro@novell.com,ro@suse.de,bugfinder@t-online.de) ---------------------------------------------------------------------- Linux Fatou 2.6.22.9-0.4-default #1 SMP 2007/10/05 21:32:04 UTC x86_64 Key fingerprint = 17DC 6553 86A7 384B 53C5 CA5C 3CE4 F2E7 23F2 B417 SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
On Oct 12 2007 23:59, Ruediger Oertel wrote:
well, the question is did people complain because of the name "bigsmp" or have there been real "functional" problems ?
It is mostly the "complain" thing (and by chance) - users get a bigsmp kernel, either through smart failing to do its job right or through other means, and when these users post to a forum or so and others notice bigsmp, they are directly questioned (since almost none of the typical users who visit linux forums actually have a big iron).
And wasn't there the story that bigsmp also uses a different memory layout (kernel/userspace split). Are there any drawbacks to that setup ?
Both default and bigsmp have 3/1G. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
Ruediger Oertel <ro@suse.de> writes:
On Fri, 12 Oct 2007, Jan Engelhardt wrote:
We tried with 10.3 but many user complained why their 1GB machine got a bigsmp kernel.
And therefore my suggestion to change it,
So the name change is because they complained they got a bigsmp? (That's how I read it.) I'd say they complained because they got a bigsmp/pae in the first place (but you may prove me wrong with a BZ entry).
well, the question is did people complain because of the name "bigsmp" or have there been real "functional" problems ? - drivers not available for bigsmp/pae
That were the first complains - and we fixed all of these.
- software not working with it (AFAIR vmware has been fixed)
There were some reports that were rather obscure but I'm not aware of it.
- functionality not working: suspend as most important feature
This has been fixed for 10.3.
Note, I'm not saying any of these don't work, I'm rather asking if they all do ?
And wasn't there the story that bigsmp also uses a different memory layout (kernel/userspace split). Are there any drawbacks to that setup ?
Andreas -- Andreas Jaeger, Director Platform/openSUSE, aj@suse.de SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
On Fri, Oct 12, 2007 at 11:59:46PM +0200, Ruediger Oertel wrote:
On Fri, 12 Oct 2007, Jan Engelhardt wrote:
We tried with 10.3 but many user complained why their 1GB machine got a bigsmp kernel.
And therefore my suggestion to change it,
So the name change is because they complained they got a bigsmp? (That's how I read it.) I'd say they complained because they got a bigsmp/pae in the first place (but you may prove me wrong with a BZ entry).
well, the question is did people complain because of the name "bigsmp" or have there been real "functional" problems ? - drivers not available for bigsmp/pae
Was fixed.
- software not working with it (AFAIR vmware has been fixed) - functionality not working: suspend as most important feature
We did not start before we had confirmation that STR and STD works.
Note, I'm not saying any of these don't work, I'm rather asking if they all do ?
That was what we both confirmend and also tried to test during Beta Test. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
Jan Engelhardt <jengelh@computergmbh.de> writes:
So the name change is because they complained they got a bigsmp? (That's how I read it.)
They complained since they just read "bigsmp" and had a Laptop.
I'd say they complained because they got a bigsmp/pae in the first place (but you may prove me wrong with a BZ entry).
They were not aware of PAE... Andreas -- Andreas Jaeger, Director Platform/openSUSE, aj@suse.de SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
* Jan Engelhardt <jengelh@computergmbh.de> [2007-10-12 17:27]:
Jeff, could you rename also kernel-bigsmp to "kernel-pae", please?
It is not just a PAEd kernel, but also allows for a higher number of CPUs. That is the "big" in bigsmp.
Yes, but we want to install the "bigsmp" kernel even on small systems if they have PAE (due to no-execute protection in the page tables). And then, everybody complains "I don't have a big SMP machine". Therefore, "pae" is the better name. And no, maintaining 3 kernels is not an option for us. Thanks, Bernhard -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Fri, Oct 12, 2007 at 05:27:58PM +0200, Jan Engelhardt wrote:
On Oct 12 2007 17:09, Andreas Jaeger wrote:
Greg KH wrote:
As 2.6.23 is now out, should we branch the 10.3 kernel tree from HEAD now? I think I'll be doing at least one more 2.6.22-stable release, which we should probably apply to the 10.3 kernel and push that out when it happens, but we should also work on moving on to 2.6.23.
Any thoughts?
Absolutely. I was going to branch it this week and try merging 2.6.23. I'd like to try to keep HEAD following mainline as closely as possible, even with no pending release. At the very least, it would be useful for handling bug reports so we can see if a particular bug has been solved in the next kernel cycle.
Jeff, could you rename also kernel-bigsmp to "kernel-pae", please?
It is not just a PAEd kernel, but also allows for a higher number of CPUs. That is the "big" in bigsmp.
We have the usability issue that Laptop users look strange if a "bigsmp" kernel gets installed (due to NX support requirements). So we would really like a neutral name here. We are open for other suggestions ;) Ciao, Marcus -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Oct 12 2007 17:43, Marcus Meissner wrote:
We have the usability issue that Laptop users look strange if a "bigsmp" kernel gets installed (due to NX support requirements).
So we would really like a neutral name here. We are open for other suggestions ;)
If you want to make bigsmp the default because of NX, then just /make/ it the default (read: kernel-default.i586.rpm) already. Renaming bigsmp to pae does not reduce the work Bernhard Walle pointed out ["And no, maintaining 3 kernels is not an option for us."] bigsmp, default, rt, xen, xenpae, uh, it's already 5 kernels :) Maintaining an extra flavor (and I'm looking onto kernel-regular) does not take much time. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Fri, Oct 12, 2007 at 06:06:01PM +0200, Jan Engelhardt wrote:
On Oct 12 2007 17:43, Marcus Meissner wrote:
We have the usability issue that Laptop users look strange if a "bigsmp" kernel gets installed (due to NX support requirements).
So we would really like a neutral name here. We are open for other suggestions ;)
If you want to make bigsmp the default because of NX, then just /make/ it the default (read: kernel-default.i586.rpm) already.
Renaming bigsmp to pae does not reduce the work Bernhard Walle pointed out ["And no, maintaining 3 kernels is not an option for us."]
bigsmp, default, rt, xen, xenpae, uh, it's already 5 kernels :) Maintaining an extra flavor (and I'm looking onto kernel-regular) does not take much time.
kernel-bigsmp -> kernel-default kernel-default -> kernel-nonpae Hmmmmmmmmmmmmmmmmmmmmmmmm Ciao, Marcus -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Fri, Oct 12, 2007 at 06:10:32PM +0200, Marcus Meissner wrote:
On Fri, Oct 12, 2007 at 06:06:01PM +0200, Jan Engelhardt wrote:
On Oct 12 2007 17:43, Marcus Meissner wrote:
We have the usability issue that Laptop users look strange if a "bigsmp" kernel gets installed (due to NX support requirements).
So we would really like a neutral name here. We are open for other suggestions ;)
If you want to make bigsmp the default because of NX, then just /make/ it the default (read: kernel-default.i586.rpm) already.
Renaming bigsmp to pae does not reduce the work Bernhard Walle pointed out ["And no, maintaining 3 kernels is not an option for us."]
bigsmp, default, rt, xen, xenpae, uh, it's already 5 kernels :) Maintaining an extra flavor (and I'm looking onto kernel-regular) does not take much time.
kernel-bigsmp -> kernel-default kernel-default -> kernel-nonpae
Hmmmmmmmmmmmmmmmmmmmmmmmm
How about bigsmp -> default and there not being anymore "non pae" kernel? Becides the memory size hit, what kinds of problems would that cause? What machines still need the "nonpae" kernel? thanks, greg k-h -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greg KH wrote:
On Fri, Oct 12, 2007 at 06:10:32PM +0200, Marcus Meissner wrote:
On Fri, Oct 12, 2007 at 06:06:01PM +0200, Jan Engelhardt wrote:
On Oct 12 2007 17:43, Marcus Meissner wrote:
We have the usability issue that Laptop users look strange if a "bigsmp" kernel gets installed (due to NX support requirements).
So we would really like a neutral name here. We are open for other suggestions ;) If you want to make bigsmp the default because of NX, then just /make/ it the default (read: kernel-default.i586.rpm) already.
Renaming bigsmp to pae does not reduce the work Bernhard Walle pointed out ["And no, maintaining 3 kernels is not an option for us."]
bigsmp, default, rt, xen, xenpae, uh, it's already 5 kernels :) Maintaining an extra flavor (and I'm looking onto kernel-regular) does not take much time. kernel-bigsmp -> kernel-default kernel-default -> kernel-nonpae
Hmmmmmmmmmmmmmmmmmmmmmmmm
How about bigsmp -> default and there not being anymore "non pae" kernel? Becides the memory size hit, what kinds of problems would that cause? What machines still need the "nonpae" kernel?
I don't know the exact models, but there were enough bug reports indicating that the bigsmp kernel didn't boot on various machines. There are definitely machines out there. I'm all for renaming kernel-bigsmp to kernel-default. kernel-nonpae works, or kernel-legacy would too. We might even want to investigate backing down the CPU optimizations on that kernel to be baseline i586 if we call it that. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFHD6X9LPWxlyuTD7IRAtjuAJ0eXCrXufHhxl8mYFeBDeEp48ceFQCbBLKB Rs3Lij3zwhJfyC7fa88vpzg= =0BJe -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Fri, Oct 12, 2007 at 12:51:09PM -0400, Jeff Mahoney wrote:
I'm all for renaming kernel-bigsmp to kernel-default.
No objection from me either.
kernel-nonpae works, or kernel-legacy would too. We might even want to investigate backing down the CPU optimizations on that kernel to be baseline i586 if we call it that.
kernel-legacy sounds good, and non "threatening" to those users who aren't running machines that are 2 years old or newer :) thanks, greg k-h -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Fri, Oct 12, 2007 at 10:05:20AM -0700, Greg KH wrote:
On Fri, Oct 12, 2007 at 12:51:09PM -0400, Jeff Mahoney wrote:
I'm all for renaming kernel-bigsmp to kernel-default.
No objection from me either.
kernel-nonpae works, or kernel-legacy would too. We might even want to investigate backing down the CPU optimizations on that kernel to be baseline i586 if we call it that.
kernel-legacy sounds good, and non "threatening" to those users who aren't running machines that are 2 years old or newer :)
Grepping over our buildsystem shows 700 PAE enabled machines and 14 that are not. So I guess "kernel-legacy" is a good call. What about Virtual Machines? Do they all expose the PAE flag? Ciao, Marcus -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Oct 12 2007 19:10, Marcus Meissner wrote:
kernel-nonpae works, or kernel-legacy would too. We might even want to investigate backing down the CPU optimizations on that kernel to be baseline i586 if we call it that.
kernel-legacy sounds good, and non "threatening" to those users who aren't running machines that are 2 years old or newer :)
I bet there's at least someone out there who will manage to mix up nvidia-legacy-gfx with kernel-legacy...
Grepping over our buildsystem shows 700 PAE enabled machines and 14 that are not. So I guess "kernel-legacy" is a good call.
So how many non-Novells actually use bigsmp over default? And do all machines that support PAE actually support NX? -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Fri, Oct 12, 2007 at 07:15:15PM +0200, Jan Engelhardt wrote:
On Oct 12 2007 19:10, Marcus Meissner wrote:
kernel-nonpae works, or kernel-legacy would too. We might even want to investigate backing down the CPU optimizations on that kernel to be baseline i586 if we call it that.
kernel-legacy sounds good, and non "threatening" to those users who aren't running machines that are 2 years old or newer :)
I bet there's at least someone out there who will manage to mix up nvidia-legacy-gfx with kernel-legacy...
Grepping over our buildsystem shows 700 PAE enabled machines and 14 that are not. So I guess "kernel-legacy" is a good call.
So how many non-Novells actually use bigsmp over default?
Good question.
And do all machines that support PAE actually support NX?
I have no good idea here. The older ones (>4 years) might not yet. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Oct 12 2007 19:16, Marcus Meissner wrote:
So how many non-Novells actually use bigsmp over default?
Good question.
actually, and accidentally.
And do all machines that support PAE actually support NX?
I have no good idea here. The older ones (>4 years) might not yet.
# Manufactured around 2003 or so # dmesg: ACPI table entries tagged 20020807 # dmesg: CPU: 20020426 17:54 official release 4.3.2#2 19:14 takeshi:~/TeamSpeak2RC2 > cat /proc/cpuinfo processor : 0 vendor_id : GenuineTMx86 cpu family : 6 model : 4 model name : Transmeta(tm) Crusoe(tm) Processor TM5800 stepping : 3 cpu MHz : 926.322 cache size : 512 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr cx8 sep cmov mmx longrun lrti constant_tsc up bogomips : 1889.16 clflush size : 32 # Manufactured around 2003 probably; purchased in June 2003: processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 8 model name : AMD Athlon(tm) XP 2000+ stepping : 0 cpu MHz : 1666.809 cache size : 256 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow up ts bogomips : 3334.88 clflush size : 32 -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
* Marcus Meissner <meissner@suse.de> [2007-10-12 19:16]:
On Fri, Oct 12, 2007 at 07:15:15PM +0200, Jan Engelhardt wrote:
On Oct 12 2007 19:10, Marcus Meissner wrote:
kernel-nonpae works, or kernel-legacy would too. We might even want to investigate backing down the CPU optimizations on that kernel to be baseline i586 if we call it that.
kernel-legacy sounds good, and non "threatening" to those users who aren't running machines that are 2 years old or newer :)
I bet there's at least someone out there who will manage to mix up nvidia-legacy-gfx with kernel-legacy...
Grepping over our buildsystem shows 700 PAE enabled machines and 14 that are not. So I guess "kernel-legacy" is a good call.
So how many non-Novells actually use bigsmp over default?
Good question.
bwalle@newton:~> cat /proc/cpuinfo processor : 0 vendor_id : CentaurHauls cpu family : 6 model : 9 model name : VIA Nehemiah stepping : 8 cpu MHz : 666.587 cache size : 64 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr cx8 sep mtrr pge cmov pat mmx fxsr sse up rng rng_en ace ace_en bogomips : 1334.63 That's not legacy, that's 1/2 year old! ;) Thanks, Bernhard -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Fri, 12 Oct 2007, Greg KH wrote:
On Fri, Oct 12, 2007 at 06:10:32PM +0200, Marcus Meissner wrote:
On Fri, Oct 12, 2007 at 06:06:01PM +0200, Jan Engelhardt wrote:
On Oct 12 2007 17:43, Marcus Meissner wrote:
We have the usability issue that Laptop users look strange if a "bigsmp" kernel gets installed (due to NX support requirements).
So we would really like a neutral name here. We are open for other suggestions ;)
If you want to make bigsmp the default because of NX, then just /make/ it the default (read: kernel-default.i586.rpm) already.
Renaming bigsmp to pae does not reduce the work Bernhard Walle pointed out ["And no, maintaining 3 kernels is not an option for us."]
bigsmp, default, rt, xen, xenpae, uh, it's already 5 kernels :) Maintaining an extra flavor (and I'm looking onto kernel-regular) does not take much time.
kernel-bigsmp -> kernel-default kernel-default -> kernel-nonpae
Hmmmmmmmmmmmmmmmmmmmmmmmm
How about bigsmp -> default and there not being anymore "non pae" kernel? Becides the memory size hit, what kinds of problems would that cause? What machines still need the "nonpae" kernel?
well, already listed in the thread: - older AMDs - transmeta I'll add: - VIA (my beloved EPIA box) You surely won't see these as compile boxes, but as routers, streaming clients, settop-boxes, ... -- with kind regards (mit freundlichem Grinsen), Ruediger Oertel (ro@novell.com,ro@suse.de,bugfinder@t-online.de) ---------------------------------------------------------------------- Linux Fatou 2.6.22.9-0.4-default #1 SMP 2007/10/05 21:32:04 UTC x86_64 Key fingerprint = 17DC 6553 86A7 384B 53C5 CA5C 3CE4 F2E7 23F2 B417 SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
On Oct 13 2007 00:01, Ruediger Oertel wrote:
well, already listed in the thread: - older AMDs - transmeta I'll add: - VIA (my beloved EPIA box)
Yup, here is another one, a fanless BA-4000[1]: scn:~ # cat /proc/cpuinfo processor : 0 vendor_id : CentaurHauls cpu family : 6 model : 9 model name : VIA Nehemiah stepping : 8 cpu MHz : 733.008 cache size : 64 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr cx8 mtrr pge cmov pat mmx fxsr sse up rng rng_en ace ace_en bogomips : 1468.17 clflush size : 32 [1] meh, they removed the page with the VIA CPU, but the Intel sister product is at http://www.atiosys.com/us/html/products/product.asp?cid=4&pid=101 (Runs opensuse 10.3 beta2 in only 348MB! - but needed to kill /usr/share/doc and tons of useless locales) -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
* Marcus Meissner <meissner@suse.de> [2007-10-12 18:10]:
kernel-bigsmp -> kernel-default kernel-default -> kernel-nonpae
I don't like this because it leads to update problem. Even if our tools handle this correctly, humans may not and if the kernel-default is unbootable on some machines ... no. Thanks, Bernhard -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
Bernhard Walle <bwalle@suse.de> writes:
* Marcus Meissner <meissner@suse.de> [2007-10-12 18:10]:
kernel-bigsmp -> kernel-default kernel-default -> kernel-nonpae
I don't like this because it leads to update problem. Even if our tools handle this correctly, humans may not and if the kernel-default is unbootable on some machines ... no.
Yeah, my suggestion was only: kernel-bigsmp -> kernel-pae And install kernel-pae by default, Andreas -- Andreas Jaeger, Director Platform/openSUSE, aj@suse.de SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
On Oct 13 2007 18:40, Andreas Jaeger wrote:
Yeah, my suggestion was only: kernel-bigsmp -> kernel-pae
And install kernel-pae by default,
Oh yeah, I vote for this one. (Though kernel-default loses its meaning if it is not default anymore :-)) -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
* Jan Engelhardt <jengelh@computergmbh.de> [2007-10-13 18:47]:
On Oct 13 2007 18:40, Andreas Jaeger wrote:
Yeah, my suggestion was only: kernel-bigsmp -> kernel-pae
And install kernel-pae by default,
Oh yeah, I vote for this one. (Though kernel-default loses its meaning if it is not default anymore :-))
Well, for SLES 10 we also have kernel-default (1 processor) and kernel-smp (SMP machines). I don't have any statistics, but I really think there are more SMP servers currently than UMP servers (HyperThreading and dual core also count as SMP). Thanks, Bernhard -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Oct 13 2007 18:55, Bernhard Walle wrote:
Well, for SLES 10 we also have kernel-default (1 processor) and kernel-smp (SMP machines). I don't have any statistics, but I really think there are more SMP servers currently than UMP servers (HyperThreading and dual core also count as SMP).
Beware of the legacy cruft machines :) [There are more than you would think.] -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
* Andreas Jaeger <aj@suse.de> [2007-10-13 18:40]:
Yeah, my suggestion was only: kernel-bigsmp -> kernel-pae
And install kernel-pae by default,
Well, only if PAE is available, right? And the installer still should use kernel-default (or ISOLINUX must detect PAE and choose the right kernel). Thanks, Bernhard -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
Bernhard Walle <bwalle@suse.de> writes:
* Andreas Jaeger <aj@suse.de> [2007-10-13 18:40]:
Yeah, my suggestion was only: kernel-bigsmp -> kernel-pae
And install kernel-pae by default,
Well, only if PAE is available, right? And the installer still should use kernel-default (or ISOLINUX must detect PAE and choose the right kernel).
Yes, that's my suggestion, Andreas -- Andreas Jaeger, Director Platform/openSUSE, aj@suse.de SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
On Oct 13 2007 20:11, Andreas Jaeger wrote:
* Andreas Jaeger <aj@suse.de> [2007-10-13 18:40]:
Yeah, my suggestion was only: kernel-bigsmp -> kernel-pae
And install kernel-pae by default,
Well, only if PAE is available, right? And the installer still should use kernel-default (or ISOLINUX must detect PAE and choose the right kernel).
Yes, that's my suggestion,
The installer may run in whatever floats the boat, which can be as low as 32-bit non-PAE. It's just the *installed* system that needs/wants to be 32-bit-PAE or 64-bit, does not it? Idea: would not this BTW reduce the number of ISOs that have to be sent to the ftps? Drawbacks? -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Sun, Oct 14, 2007 at 12:11:22AM +0200, Jan Engelhardt wrote:
On Oct 13 2007 20:11, Andreas Jaeger wrote:
* Andreas Jaeger <aj@suse.de> [2007-10-13 18:40]:
Yeah, my suggestion was only: kernel-bigsmp -> kernel-pae
And install kernel-pae by default,
Well, only if PAE is available, right? And the installer still should use kernel-default (or ISOLINUX must detect PAE and choose the right kernel).
Yes, that's my suggestion,
The installer may run in whatever floats the boat, which can be as low as 32-bit non-PAE. It's just the *installed* system that needs/wants to be 32-bit-PAE or 64-bit, does not it? Idea: would not this BTW reduce the number of ISOs that have to be sent to the ftps? Drawbacks?
The installer runs of course without PAE. This would change nothing and hadn't there been reported problems would have happened with 10.3 as-is without any noticable difference. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Oct 14 2007 01:17, Marcus Meissner wrote:
The installer may run in whatever floats the boat, which can be as low as 32-bit non-PAE. It's just the *installed* system that needs/wants to be 32-bit-PAE or 64-bit, does not it? Idea: would not this BTW reduce the number of ISOs that have to be sent to the ftps? Drawbacks?
The installer runs of course without PAE.
This would change nothing and hadn't there been reported problems would have happened with 10.3 as-is without any noticable difference.
(Just in case you missed: would not it make sense to run the installer always in 32-bit mode?) -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jan Engelhardt wrote:
On Oct 14 2007 01:17, Marcus Meissner wrote:
The installer may run in whatever floats the boat, which can be as low as 32-bit non-PAE. It's just the *installed* system that needs/wants to be 32-bit-PAE or 64-bit, does not it? Idea: would not this BTW reduce the number of ISOs that have to be sent to the ftps? Drawbacks? The installer runs of course without PAE.
This would change nothing and hadn't there been reported problems would have happened with 10.3 as-is without any noticable difference.
(Just in case you missed: would not it make sense to run the installer always in 32-bit mode?)
No. When installing 64 bit packages, post-install scripts would want to use the installed binaries. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFHEYeSLPWxlyuTD7IRAgY/AKCMME4oqemYghYCGWX/ZqRBOndt7wCcCAOl GhCOYxbaansatFH8J4EzFaY= =7ZSe -----END PGP SIGNATURE----- -- Jeff Mahoney SUSE Labs -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Sat, 13 Oct 2007, Jeff Mahoney wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Jan Engelhardt wrote:
On Oct 14 2007 01:17, Marcus Meissner wrote:
The installer may run in whatever floats the boat, which can be as low as 32-bit non-PAE. It's just the *installed* system that needs/wants to be 32-bit-PAE or 64-bit, does not it? Idea: would not this BTW reduce the number of ISOs that have to be sent to the ftps? Drawbacks? The installer runs of course without PAE.
This would change nothing and hadn't there been reported problems would have happened with 10.3 as-is without any noticable difference.
(Just in case you missed: would not it make sense to run the installer always in 32-bit mode?)
No. When installing 64 bit packages, post-install scripts would want to use the installed binaries.
same for hardware configuration, there is no guarantee that the configuration uses the same drivers and/or settings for 32/64 bit. -- with kind regards (mit freundlichem Grinsen), Ruediger Oertel (ro@novell.com,ro@suse.de,bugfinder@t-online.de) ---------------------------------------------------------------------- Linux Fatou 2.6.22.9-0.4-default #1 SMP 2007/10/05 21:32:04 UTC x86_64 Key fingerprint = 17DC 6553 86A7 384B 53C5 CA5C 3CE4 F2E7 23F2 B417 SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
On Oct 10 2007 11:33, Greg KH wrote:
As 2.6.23 is now out, should we branch the 10.3 kernel tree from HEAD now? I think I'll be doing at least one more 2.6.22-stable release, which we should probably apply to the 10.3 kernel and push that out when it happens, but we should also work on moving on to 2.6.23.
Any thoughts?
Yup, do 2.6.22.10 for 10.3, fix the root hole[1] in 10.2, then move on :-) [1] 176df2457ef6207156ca1a40991c54ca01fef567 -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jan Engelhardt wrote:
On Oct 10 2007 11:33, Greg KH wrote:
As 2.6.23 is now out, should we branch the 10.3 kernel tree from HEAD now? I think I'll be doing at least one more 2.6.22-stable release, which we should probably apply to the 10.3 kernel and push that out when it happens, but we should also work on moving on to 2.6.23.
Any thoughts?
Yup, do 2.6.22.10 for 10.3, fix the root hole[1] in 10.2, then move on :-)
[1] 176df2457ef6207156ca1a40991c54ca01fef567
The fix for that one is going through QA and will be released RSN. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFHDTzGLPWxlyuTD7IRApPMAJ4x0WDr4U4k2DKTLEmCWYcBc5yqtACbBjcC M90O2lUAZJ76e8UzKSv11uc= =Whed -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Wed, Oct 10, 2007 at 10:47:17PM +0200, Jan Engelhardt wrote:
On Oct 10 2007 11:33, Greg KH wrote:
As 2.6.23 is now out, should we branch the 10.3 kernel tree from HEAD now? I think I'll be doing at least one more 2.6.22-stable release, which we should probably apply to the 10.3 kernel and push that out when it happens, but we should also work on moving on to 2.6.23.
Any thoughts?
Yup, do 2.6.22.10 for 10.3,
2.6.22.10 is already checked into the 10.3 tree and will be in the next kernel-of-the-day build for people to use tomorrow. Actually the build today already has the 10-rc1 patch in it, if people want/need it now. thanks, greg k-h -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Oct 10 2007 22:47, Jan Engelhardt wrote:
On Oct 10 2007 11:33, Greg KH wrote:
As 2.6.23 is now out, should we branch the 10.3 kernel tree from HEAD now? I think I'll be doing at least one more 2.6.22-stable release, which we should probably apply to the 10.3 kernel and push that out when it happens, but we should also work on moving on to 2.6.23.
Any thoughts?
Yup, do 2.6.22.10 for 10.3, fix the root hole[1] in 10.2, then move on :-)
[1] 176df2457ef6207156ca1a40991c54ca01fef567
Hm, while we are at it, could the specfiles be changed per the suggestion of http://lists.opensuse.org/opensuse-packaging/2007-10/msg00024.html ? See this patch.. diff -dpru 165.1/kernel-default.spec new/kernel-default.spec --- 165.1/kernel-default.spec 2007-10-10 22:59:01.899393000 +0200 +++ new/kernel-default.spec 2007-10-10 23:04:38.015522193 +0200 @@ -37,7 +37,7 @@ %define build_vanilla 1 %endif -Name: kernel-default +Name: kernel-%build_flavor Summary: Dummy summary Version: 2.6.22.9 Release: 0 @@ -88,8 +88,8 @@ Requires: irqbalance Requires: xen >= xen-3.0.2_09697 #!BuildIgnore: xen %endif -Provides: kernel-default-nongpl -Obsoletes: kernel-default-nongpl +Provides: %name-nongpl +Obsoletes: %name-nongpl Conflicts: apparmor-profiles <= 2.0.1 Conflicts: apparmor-parser <= 2.0.1 Conflicts: sysfsutils < 2.0 @@ -97,7 +97,7 @@ Conflicts: sysfsutils < 2.0 #Conflicts: kernel %else %if ! %build_xen -Provides: kernel = 2.6.22.9-%source_rel +Provides: kernel = %version-%source_rel %endif %endif %ifarch alpha @@ -186,7 +186,7 @@ NoSource: 120 %(chmod +x %_sourcedir/{arch-symbols,guards,config-subst,check-for-config-changes,check-supported-list,built-in-where,find-provides,make-symsets,find-types,kabi-checks,install-configs}) -%define symbols %(set -- kernel-default default $(case default in (rt|rt_*) echo RT ;; esac) $(%_sourcedir/arch-symbols %_target_cpu) $([ -e %_sourcedir/extra-symbols ] && cat %_sourcedir/extra-symbols) ; echo $*) +%define symbols %(set -- kernel-%build_flavor %build_flavor $(case %build_flavor in (rt|rt_*) echo RT ;; esac) $(%_sourcedir/arch-symbols %_target_cpu) $([ -e %_sourcedir/extra-symbols ] && cat %_sourcedir/extra-symbols) ; echo $*) # Provide the exported symbols as "ksym(symbol) = hash" %define __find_provides %_sourcedir/find-provides %name @@ -205,8 +205,8 @@ Dummy description. %prep if ! [ -e %_sourcedir/linux-2.6.22.tar.bz2 ]; then - echo "The kernel-default-2.6.22.9.nosrc.rpm package does not contain the" \ - "complete sources. Please install kernel-source-2.6.22.9.src.rpm." + echo "The %name-%version.nosrc.rpm package does not contain the" \ + "complete sources. Please install %name-%version.src.rpm." exit 1 fi @@ -235,7 +235,7 @@ cd linux-2.6.22 # tells us for which architecture to compile. set -- $( for config in $(%_sourcedir/guards %symbols < %_sourcedir/config.conf) ; do - [ ${config#*/} = default ] && echo $config + [ ${config#*/} = %build_flavor ] && echo $config done) if [ $# -ne 1 ]; then echo "$# config files found for this spec file (but one needed)" >&2 @@ -261,7 +261,7 @@ done %endif %_sourcedir/install-configs %_sourcedir %my_builddir %source_rel -config=arch/$subarch/defconfig.default +config=arch/$subarch/defconfig.%build_flavor cat $config \ %if 0%{?__debug_package:1} | %_sourcedir/config-subst CONFIG_DEBUG_INFO y \ @@ -271,9 +271,9 @@ cat $config \ # We compile for this sub-architecture (i.e., machine architecture): %if %build_um cat > ../.rpm-defs <<EOF -ARCH=default +ARCH=%build_flavor SUBARCH=$subarch -MAKE_ARGS="ARCH=default SUBARCH=$subarch" +MAKE_ARGS="ARCH=%build_flavor SUBARCH=$subarch" EOF %else cat > ../.rpm-defs <<EOF @@ -306,8 +306,8 @@ rm .config.orig make prepare $MAKE_ARGS KERNELRELEASE=$(make -s kernelrelease $MAKE_ARGS) -if [ 2.6.22.9-%source_rel != ${KERNELRELEASE%%-*} ]; then - echo "Kernel release mismatch: 2.6.22.9-%source_rel" \ +if [ %version-%source_rel != ${KERNELRELEASE%%-*} ]; then + echo "Kernel release mismatch: %version-%source_rel" \ "!= ${KERNELRELEASE%%-*}" >&2 exit 1 fi @@ -440,25 +440,25 @@ add_vmlinux() sed -e "s:@KERNELRELEASE@:$KERNELRELEASE:g" \ -e "s:@IMAGE@:$image:g" \ - -e "s:@FLAVOR""@:default:g" \ + -e "s:@FLAVOR""@:%build_flavor:g" \ %_sourcedir/pre.sh > ../pre.sh ( cat %_sourcedir/functions.sh sed -e "s:@KERNELRELEASE@:$KERNELRELEASE:g" \ -e "s:@IMAGE@:$image:g" \ - -e "s:@FLAVOR""@:default:g" \ + -e "s:@FLAVOR""@:%build_flavor:g" \ %_sourcedir/post.sh ) > ../post.sh ( cat %_sourcedir/functions.sh sed -e "s:@KERNELRELEASE@:$KERNELRELEASE:g" \ -e "s:@IMAGE@:$image:g" \ - -e "s:@FLAVOR""@:default:g" \ + -e "s:@FLAVOR""@:%build_flavor:g" \ %_sourcedir/postun.sh ) > ../postun.sh %if %build_kdump || %build_um || %build_xen || %build_vanilla -suffix=-default +suffix=-%build_flavor %endif ln -s $image$suffix %buildroot/boot/$image$suffix ln -s initrd$suffix %buildroot/boot/initrd$suffix @@ -479,7 +479,7 @@ gzip -c9 < Module.symvers > %buildroot/b # Group the exported symbols listed in symvers.gz by directory, and # create a database of sets. Preserve exports from previous kernels # (stored in old-symsets.tar.gz) when possible. -old_symsets=%my_builddir/kabi/$SUBARCH/symsets-default.tar.gz +old_symsets=%my_builddir/kabi/$SUBARCH/symsets-%build_flavor.tar.gz [ -e $old_symsets ] || old_symsets= ( grep -v $'\tvmlinux$' Module.symvers # Find out in which built-in.o files the exported symbols that ended @@ -489,12 +489,12 @@ old_symsets=%my_builddir/kabi/$SUBARCH/s %buildroot/boot/symsets-$KERNELRELEASE.tar.gz \ $old_symsets -# Also put the resulting file in $obj_dir/$SUBARCH/default -# so that kernel-source + kernel-default is sufficient for building +# Also put the resulting file in $obj_dir/$SUBARCH/%build_flavor +# so that kernel-source + kernel-%build_flavor is sufficient for building # modules that have modversions as well. -obj_dir=usr/src/linux-${KERNELRELEASE%%-default}-obj -mkdir -p %buildroot/$obj_dir/$SUBARCH/default -cp Module.symvers %buildroot/$obj_dir/$SUBARCH/default +obj_dir=usr/src/linux-${KERNELRELEASE%%-%build_flavor}-obj +mkdir -p %buildroot/$obj_dir/$SUBARCH/%build_flavor +cp Module.symvers %buildroot/$obj_dir/$SUBARCH/%build_flavor # Table of types used in exported symbols (for modversion debugging). %_sourcedir/find-types > %buildroot/boot/symtypes-$KERNELRELEASE @@ -523,7 +523,7 @@ fi # # create configfile for makedumpfile utility (see makedumpfile(8)) to # create smaller kdump images -CONFIGFILE=%buildroot/$obj_dir/$SUBARCH/default/makedumpfile.config +CONFIGFILE=%buildroot/$obj_dir/$SUBARCH/%build_flavor/makedumpfile.config makedumpfile -x %buildroot/usr/lib/debug/boot/vmlinux-$KERNELRELEASE.debug \ -g $CONFIGFILE || true # failure should not fail the build @@ -557,9 +557,9 @@ fi # Check for kABI changes KABI=0 -if [ -e %my_builddir/kabi/$SUBARCH/symvers-default ]; then +if [ -e %my_builddir/kabi/$SUBARCH/symvers-%build_flavor ]; then %_sourcedir/kabi-checks \ - %my_builddir/kabi/$SUBARCH/symvers-default \ + %my_builddir/kabi/$SUBARCH/symvers-%build_flavor \ Module.symvers \ %my_builddir/kabi/commonsyms \ %my_builddir/kabi/usedsyms \ @@ -568,7 +568,7 @@ fi if [ $KABI -gt %tolerate_kabi_changes ]; then echo "kABI changes of badness $KABI exceed the maximum allowed badness" \ "of %tolerate_kabi_changes. Please try to avoid the kABI changes." - if [ ! -e %my_builddir/kabi/$SUBARCH/ignore-default -a \ + if [ ! -e %my_builddir/kabi/$SUBARCH/ignore-%build_flavor -a \ ! -e %_sourcedir/IGNORE-KABI-BADNESS ]; then echo "Create a file IGNORE-KABI-BADNESS in the kernel-source" \ "directory to build this kernel even though its badness is" \ @@ -589,9 +589,9 @@ fi # later be installed in /usr/src/linux-2.6.22-%source_rel. Fix up the # build symlink. rm -f %buildroot/lib/modules/$KERNELRELEASE/{source,build} -ln -s /usr/src/linux-${KERNELRELEASE%%-default} \ +ln -s /usr/src/linux-${KERNELRELEASE%%-%build_flavor} \ %buildroot/lib/modules/$KERNELRELEASE/source -ln -s /$obj_dir/$SUBARCH/default \ +ln -s /$obj_dir/$SUBARCH/%build_flavor \ %buildroot/lib/modules/$KERNELRELEASE/build # Abort if there are any undefined symbols diff -dpru 165.1/kernel-source.spec new/kernel-source.spec --- 165.1/kernel-source.spec 2007-10-10 22:59:02.329362000 +0200 +++ new/kernel-source.spec 2007-10-10 23:04:19.656826034 +0200 @@ -31,8 +31,8 @@ BuildRequires: coreutils BuildRequires: kernel-dummy %endif Provides: linux -Provides: kernel-source = 2.6.22.9-%source_rel -%if "kernel-source" == "kernel-source" +Provides: %name = %version-%source_rel +%if "%name" == "kernel-source" Provides: linux lx_suse lx_sus22 lx_sus24 Obsoletes: linux lx-gdt lx-hack lx-suse lx1162_1 lx1162_2 lx1212_1 lx1212_2 lx1213_1 lx1213_2 lx121_1 lx121_2 lx126_1 lx126_2 lx129_1 lx129_2 lx_large kernel_headers lx_suse lx_sus22 lx_sus24 %endif @@ -124,17 +124,17 @@ chmod -Rf a+rX,g-w,o-w . # Apply the patches needed for this architecture. %_sourcedir/guards %symbols < %_sourcedir/series.conf \ - > %_builddir/kernel-source-2.6.22.9/kernel-source.patches -for patch in $(< %_builddir/kernel-source-2.6.22.9/kernel-source.patches); do - if ! patch -s -E -p1 --no-backup-if-mismatch -i %_builddir/kernel-source-2.6.22.9/$patch; then + > %_builddir/%name-%version/kernel-source.patches +for patch in $(< %_builddir/%name-%version/kernel-source.patches); do + if ! patch -s -E -p1 --no-backup-if-mismatch -i %_builddir/%name-%version/$patch; then echo "*** Patch $patch failed ***" exit 1 fi done -%_sourcedir/install-configs %_sourcedir %_builddir/kernel-source-2.6.22.9 %source_rel +%_sourcedir/install-configs %_sourcedir %_builddir/%name-%version %source_rel -KERNELRELEASE=2.6.22.9-%source_rel +KERNELRELEASE=%version-%source_rel cat > %_builddir/%{name}-%{version}/.rpm-defs <<EOF KERNELRELEASE=$KERNELRELEASE SYMBOLS="%symbols" @@ -161,8 +161,8 @@ for config in $(%_sourcedir/guards %symb set -- kernel-$flavor $flavor $(case $flavor in (rt|rt_*) echo RT ;; esac) %_sourcedir/guards $* %symbols < %_sourcedir/series.conf \ - > %_builddir/kernel-source-2.6.22.9/kernel-$flavor.patches - diff -q %_builddir/kernel-source-2.6.22.9/kernel-{source,$flavor}.patches \ + > %_builddir/%name-%version/kernel-$flavor.patches + diff -q %_builddir/%name-%version/kernel-{source,$flavor}.patches \ || continue o=$RPM_BUILD_ROOT/usr/src/linux-$KERNELRELEASE-obj/$arch/$flavor -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Wed, Oct 10, 2007 at 11:05:08PM +0200, Jan Engelhardt wrote:
On Oct 10 2007 22:47, Jan Engelhardt wrote:
On Oct 10 2007 11:33, Greg KH wrote:
As 2.6.23 is now out, should we branch the 10.3 kernel tree from HEAD now? I think I'll be doing at least one more 2.6.22-stable release, which we should probably apply to the 10.3 kernel and push that out when it happens, but we should also work on moving on to 2.6.23.
Any thoughts?
Yup, do 2.6.22.10 for 10.3, fix the root hole[1] in 10.2, then move on :-)
[1] 176df2457ef6207156ca1a40991c54ca01fef567
Hm, while we are at it, could the specfiles be changed per the suggestion of http://lists.opensuse.org/opensuse-packaging/2007-10/msg00024.html ?
See this patch..
Hm, I do not think this is going to work as we generate those spec files automatically from out build process. The "raw" spec files already look like much of what you have proposed, so there isn't really anything needing to be changed here. What is the main issue? It's just hard to generate new packages from these spec files? thanks, greg k-h -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Oct 10 2007 14:14, Greg KH wrote:
See this patch..
Hm, I do not think this is going to work as we generate those spec files automatically from out build process. The "raw" spec files already look like much of what you have proposed, so there isn't really anything needing to be changed here.
The raw specfiles are not yet provided. And, I think rpm specfiles should really use rpm magic where possible, and not so much s/// magic.
What is the main issue? It's just hard to generate new packages from these spec files?
At the moment somewhere between hard and just-very-time-consuming. It took me quite some time (probably half a day) to mock up kernel-source.spec so much that the -rt kernel can also have a /usr/src/linux/ source thing so you can build KMPs against it. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Wednesday 10 October 2007 23:05:08 Jan Engelhardt wrote:
Hm, while we are at it, could the specfiles be changed per the suggestion of http://lists.opensuse.org/opensuse-packaging/2007-10/msg00024.html ?
See this patch..
diff -dpru 165.1/kernel-default.spec new/kernel-default.spec --- 165.1/kernel-default.spec 2007-10-10 22:59:01.899393000 +0200 +++ new/kernel-default.spec 2007-10-10 23:04:38.015522193 +0200 @@ -37,7 +37,7 @@ %define build_vanilla 1 %endif
-Name: kernel-default +Name: kernel-%build_flavor
Probably not *exactly* like that, but I would really like to put our templates and related scripts into kernel-source.src.rpm. We are not holding them back because they are highly secret, but because nobody yet had the time to look into this, sorry. Thanks, Andreas -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Wed, Oct 10, 2007 at 10:47:17PM +0200, Jan Engelhardt wrote:
On Oct 10 2007 11:33, Greg KH wrote:
As 2.6.23 is now out, should we branch the 10.3 kernel tree from HEAD now? I think I'll be doing at least one more 2.6.22-stable release, which we should probably apply to the 10.3 kernel and push that out when it happens, but we should also work on moving on to 2.6.23.
Any thoughts?
Yup, do 2.6.22.10 for 10.3, fix the root hole[1] in 10.2, then move on :-)
[1] 176df2457ef6207156ca1a40991c54ca01fef567
Updated kernels were released today. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
participants (8)
-
Andreas Gruenbacher -
Andreas Jaeger -
Bernhard Walle -
Greg KH -
Jan Engelhardt -
Jeff Mahoney -
Marcus Meissner -
Ruediger Oertel