From jwilson at redhat.com Mon Jul 2 15:51:02 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Mon, 02 Jul 2007 11:51:02 -0400 Subject: spec hacks for vanilla and git-based kernel rpm builds In-Reply-To: <20070608203730.BF4E84D05A0@magilla.localdomain> References: <20070608203730.BF4E84D05A0@magilla.localdomain> Message-ID: <46891EE6.1060402@redhat.com> Roland McGrath wrote: > Oops, I accidentally checked in my Makefile too. So I guess I'll just > assume you thought its changes were good. ;-) > > This one copies some extras-style boilerplate that is necessary if you have > a whole-tree checkout of /cvs/pkgs/rpms. It does not give you individual > foobar/common/ checkouts like it will if you do "cvs co foobar", and the > old extras style was for everything to use your single common/ checkout at > the top. This is now the standard boilerplate apparently, which every > formerly Core package needs to work with whole-tree checkouts. > > The rest (cvs diff -r 1.49 -r 1.50 Makefile) is all additions at the end. > You can use "make vanilla-x86_64" or "make vanilla-prep" or whatnot, > and various git/blah targets. The details were previously discussed here, > and are in comments in the makefile additions. So I finally got around to poking at these bits again myself (in relation to bug 240878), but ran into an issue with a vanilla/nopatches build: $ rpmbuild -bb --with baseonly --define 'nopatches 1' kernel-2.6.spec RPM build errors: File not found: /data/buildroot/tmp/kernel-2.6.21-1.3243.fc8-root-x86_64/usr/src/debug/kernel-vanilla-2.6.21/linux-2.6.21.x86_64 There exists a .../debug/kernel-2.6.21/linux-2.6.21.x86_64 though. (Looking into it more now, but figured I'd throw it out there, in case someone already knows what's up). Also, anyone have thoughts on re-versioning, at least in the vanilla case, so as to more accurately describe what's being built? For example, the above is 2.6.22-rc4-git6, so I'm a fan of the package that gets churned out being kernel-vanilla-2.6.22-0.1.rc4.git6.fc8 or some such thing, instead of kernel-vanilla-2.6.21-1.3243.fc8. -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From davej at redhat.com Mon Jul 2 15:57:19 2007 From: davej at redhat.com (Dave Jones) Date: Mon, 2 Jul 2007 11:57:19 -0400 Subject: spec hacks for vanilla and git-based kernel rpm builds In-Reply-To: <46891EE6.1060402@redhat.com> References: <20070608203730.BF4E84D05A0@magilla.localdomain> <46891EE6.1060402@redhat.com> Message-ID: <20070702155719.GC729@redhat.com> On Mon, Jul 02, 2007 at 11:51:02AM -0400, Jarod Wilson wrote: > Also, anyone have thoughts on re-versioning, at least in the vanilla > case, so as to more accurately describe what's being built? For example, > the above is 2.6.22-rc4-git6, so I'm a fan of the package that gets > churned out being kernel-vanilla-2.6.22-0.1.rc4.git6.fc8 or some such > thing, instead of kernel-vanilla-2.6.21-1.3243.fc8. I'd like to give this a shot for f8. Doing it for the -vanilla packages is a 'must-have', and if it works out there, there's no reason not to do it in all the packages. Dave -- http://www.codemonkey.org.uk From jwilson at redhat.com Mon Jul 2 16:00:59 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Mon, 02 Jul 2007 12:00:59 -0400 Subject: spec hacks for vanilla and git-based kernel rpm builds In-Reply-To: <20070702155719.GC729@redhat.com> References: <20070608203730.BF4E84D05A0@magilla.localdomain> <46891EE6.1060402@redhat.com> <20070702155719.GC729@redhat.com> Message-ID: <4689213B.3040509@redhat.com> Dave Jones wrote: > On Mon, Jul 02, 2007 at 11:51:02AM -0400, Jarod Wilson wrote: > > > Also, anyone have thoughts on re-versioning, at least in the vanilla > > case, so as to more accurately describe what's being built? For example, > > the above is 2.6.22-rc4-git6, so I'm a fan of the package that gets > > churned out being kernel-vanilla-2.6.22-0.1.rc4.git6.fc8 or some such > > thing, instead of kernel-vanilla-2.6.21-1.3243.fc8. > > I'd like to give this a shot for f8. Doing it for the -vanilla packages > is a 'must-have', and if it works out there, there's no reason not > to do it in all the packages. Cool, I've got an implementation of this for kernel-vanilla I did a while back that I can resurrect and fire along for review. -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From jwboyer at jdub.homelinux.org Mon Jul 2 16:00:59 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 02 Jul 2007 11:00:59 -0500 Subject: spec hacks for vanilla and git-based kernel rpm builds In-Reply-To: <20070702155719.GC729@redhat.com> References: <20070608203730.BF4E84D05A0@magilla.localdomain> <46891EE6.1060402@redhat.com> <20070702155719.GC729@redhat.com> Message-ID: <1183392059.16523.22.camel@weaponx.rchland.ibm.com> On Mon, 2007-07-02 at 11:57 -0400, Dave Jones wrote: > On Mon, Jul 02, 2007 at 11:51:02AM -0400, Jarod Wilson wrote: > > > Also, anyone have thoughts on re-versioning, at least in the vanilla > > case, so as to more accurately describe what's being built? For example, > > the above is 2.6.22-rc4-git6, so I'm a fan of the package that gets > > churned out being kernel-vanilla-2.6.22-0.1.rc4.git6.fc8 or some such > > thing, instead of kernel-vanilla-2.6.21-1.3243.fc8. > > I'd like to give this a shot for f8. Doing it for the -vanilla packages > is a 'must-have', and if it works out there, there's no reason not > to do it in all the packages. Yay! josh From davej at redhat.com Mon Jul 2 16:27:19 2007 From: davej at redhat.com (Dave Jones) Date: Mon, 2 Jul 2007 12:27:19 -0400 Subject: spec hacks for vanilla and git-based kernel rpm builds In-Reply-To: <1183392059.16523.22.camel@weaponx.rchland.ibm.com> References: <20070608203730.BF4E84D05A0@magilla.localdomain> <46891EE6.1060402@redhat.com> <20070702155719.GC729@redhat.com> <1183392059.16523.22.camel@weaponx.rchland.ibm.com> Message-ID: <20070702162719.GA24863@redhat.com> On Mon, Jul 02, 2007 at 11:00:59AM -0500, Josh Boyer wrote: > On Mon, 2007-07-02 at 11:57 -0400, Dave Jones wrote: > > On Mon, Jul 02, 2007 at 11:51:02AM -0400, Jarod Wilson wrote: > > > > > Also, anyone have thoughts on re-versioning, at least in the vanilla > > > case, so as to more accurately describe what's being built? For example, > > > the above is 2.6.22-rc4-git6, so I'm a fan of the package that gets > > > churned out being kernel-vanilla-2.6.22-0.1.rc4.git6.fc8 or some such > > > thing, instead of kernel-vanilla-2.6.21-1.3243.fc8. > > > > I'd like to give this a shot for f8. Doing it for the -vanilla packages > > is a 'must-have', and if it works out there, there's no reason not > > to do it in all the packages. > > Yay! There's another reason I'd like to get this done for F8. I'd still really like us to ship 2.6.23 for f8, but with the shorter devel schedule, it's unclear if it's going to land upstream in time. We've shipped -rc's as GA kernels before, but I always felt 'dirty' for doing this (especially when we name them incorrectly). Shipping it with 'rc3' or whatever in the title seems a little more honest at least about what we're shipping, and at the same time, it prevents bad reviewers from writing "Fedora still ships with a 2.6.22 kernel". Dave -- http://www.codemonkey.org.uk From jonathan.underwood at gmail.com Mon Jul 2 16:50:13 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Mon, 2 Jul 2007 17:50:13 +0100 Subject: spec hacks for vanilla and git-based kernel rpm builds In-Reply-To: <20070702162719.GA24863@redhat.com> References: <20070608203730.BF4E84D05A0@magilla.localdomain> <46891EE6.1060402@redhat.com> <20070702155719.GC729@redhat.com> <1183392059.16523.22.camel@weaponx.rchland.ibm.com> <20070702162719.GA24863@redhat.com> Message-ID: <645d17210707020950q7a0ed204uba00930a9ff061fc@mail.gmail.com> On 02/07/07, Dave Jones wrote: > There's another reason I'd like to get this done for F8. > I'd still really like us to ship 2.6.23 for f8, but with the shorter > devel schedule, it's unclear if it's going to land upstream in time. > We've shipped -rc's as GA kernels before, but I always felt 'dirty' for > doing this (especially when we name them incorrectly). > Shipping it with 'rc3' or whatever in the title seems a little more > honest at least about what we're shipping, and at the same time, > it prevents bad reviewers from writing "Fedora still ships with a 2.6.22 > kernel". Sort of related to this - it's (usually? often?) the case that the shipped kernel is based on a "stable" point release - eg. on this F-7 box, the kernel is based on 2.6.21.2 according to the %changelog, and yet the kernel rpm is kernel-2.6.21-1.3228. Would it not be sensible to also add that last point number? Jonathan. ps. Sorry to Dave for sending this mail to him alone rather than the list pps. Why does this list not set the Reply-To to the list rather than the message sender? From fedora at leemhuis.info Mon Jul 2 17:27:17 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 02 Jul 2007 19:27:17 +0200 Subject: spec hacks for vanilla and git-based kernel rpm builds In-Reply-To: <20070702162719.GA24863@redhat.com> References: <20070608203730.BF4E84D05A0@magilla.localdomain> <46891EE6.1060402@redhat.com> <20070702155719.GC729@redhat.com> <1183392059.16523.22.camel@weaponx.rchland.ibm.com> <20070702162719.GA24863@redhat.com> Message-ID: <46893575.60105@leemhuis.info> On 02.07.2007 18:27, Dave Jones wrote: > On Mon, Jul 02, 2007 at 11:00:59AM -0500, Josh Boyer wrote: > > On Mon, 2007-07-02 at 11:57 -0400, Dave Jones wrote: > > > On Mon, Jul 02, 2007 at 11:51:02AM -0400, Jarod Wilson wrote: > > > > > > > Also, anyone have thoughts on re-versioning, at least in the vanilla > > > > case, so as to more accurately describe what's being built? For example, > > > > the above is 2.6.22-rc4-git6, so I'm a fan of the package that gets > > > > churned out being kernel-vanilla-2.6.22-0.1.rc4.git6.fc8 or some such > > > > thing, instead of kernel-vanilla-2.6.21-1.3243.fc8. > > > > > > I'd like to give this a shot for f8. Doing it for the -vanilla packages > > > is a 'must-have', and if it works out there, there's no reason not > > > to do it in all the packages. > There's another reason I'd like to get this done for F8. > I'd still really like us to ship 2.6.23 for f8, but with the shorter > devel schedule, it's unclear if it's going to land upstream in time. > We've shipped -rc's as GA kernels before, but I always felt 'dirty' for > doing this (especially when we name them incorrectly). I'd say it's unlikely that 2.6.23 is not ready in time for F8. Some statistics that lead to my opinion: 2.6.18 took 94 days to develop 2.6.19 took 71 days 2.6.20 took 66 days 2.6.21 took 80 days 2.6.22 is about 5-7 days away afaics; so it will have had around 73 days to get finished. Final devel freeze for F8 currently is 24 October 2007 -- that's 114 days away from now; minus those ~6 days until 2.6.22; that leaves around 108 days for 2.6.23 to mature in time for the F8 freeze. I'd say that should work out when I look at the numbers from recent kernels found above. > Shipping it with 'rc3' or whatever in the title seems a little more > honest at least about what we're shipping, and at the same time, > it prevents bad reviewers from writing "Fedora still ships with a 2.6.22 > kernel". A proper kernel naming would help there as well (e.g. name the kernels just as upstream -- e.g. 2.6.23-rc[1-7]{,.git[0-9]*). ;-) Yeah, this old topic again that never got solved. CU thl From davej at redhat.com Mon Jul 2 17:39:57 2007 From: davej at redhat.com (Dave Jones) Date: Mon, 2 Jul 2007 13:39:57 -0400 Subject: spec hacks for vanilla and git-based kernel rpm builds In-Reply-To: <46893575.60105@leemhuis.info> References: <20070608203730.BF4E84D05A0@magilla.localdomain> <46891EE6.1060402@redhat.com> <20070702155719.GC729@redhat.com> <1183392059.16523.22.camel@weaponx.rchland.ibm.com> <20070702162719.GA24863@redhat.com> <46893575.60105@leemhuis.info> Message-ID: <20070702173957.GA6403@redhat.com> On Mon, Jul 02, 2007 at 07:27:17PM +0200, Thorsten Leemhuis wrote: > > I'd still really like us to ship 2.6.23 for f8, but with the shorter > > devel schedule, it's unclear if it's going to land upstream in time. > > We've shipped -rc's as GA kernels before, but I always felt 'dirty' for > > doing this (especially when we name them incorrectly). > > I'd say it's unlikely that 2.6.23 is not ready in time for F8. Some > statistics that lead to my opinion: > > 2.6.18 took 94 days to develop > 2.6.19 took 71 days > 2.6.20 took 66 days > 2.6.21 took 80 days > > 2.6.22 is about 5-7 days away afaics; so it will have had around 73 days > to get finished. > > Final devel freeze for F8 currently is 24 October 2007 -- that's 114 > days away from now; minus those ~6 days until 2.6.22; that leaves around > 108 days for 2.6.23 to mature in time for the F8 freeze. I'd say that > should work out when I look at the numbers from recent kernels found above. The concerns I have is that summertime is usually a slower period. People go to conferences, summits, beaches a lot more, so it could drag out a little. But based on your numbers, there is quite a bit of room for lag in there, so it's still plausible that we'll make it by October. > > Shipping it with 'rc3' or whatever in the title seems a little more > > honest at least about what we're shipping, and at the same time, > > it prevents bad reviewers from writing "Fedora still ships with a 2.6.22 > > kernel". > > A proper kernel naming would help there as well (e.g. name the kernels > just as upstream -- e.g. 2.6.23-rc[1-7]{,.git[0-9]*). ;-) Yeah, this old > topic again that never got solved. Indeed. That's what Jarod was proposing to fix no? Dave -- http://www.codemonkey.org.uk From davej at redhat.com Mon Jul 2 17:41:52 2007 From: davej at redhat.com (Dave Jones) Date: Mon, 2 Jul 2007 13:41:52 -0400 Subject: spec hacks for vanilla and git-based kernel rpm builds In-Reply-To: <645d17210707020950q7a0ed204uba00930a9ff061fc@mail.gmail.com> References: <20070608203730.BF4E84D05A0@magilla.localdomain> <46891EE6.1060402@redhat.com> <20070702155719.GC729@redhat.com> <1183392059.16523.22.camel@weaponx.rchland.ibm.com> <20070702162719.GA24863@redhat.com> <645d17210707020950q7a0ed204uba00930a9ff061fc@mail.gmail.com> Message-ID: <20070702174152.GB6403@redhat.com> On Mon, Jul 02, 2007 at 05:50:13PM +0100, Jonathan Underwood wrote: > On 02/07/07, Dave Jones wrote: > > There's another reason I'd like to get this done for F8. > > I'd still really like us to ship 2.6.23 for f8, but with the shorter > > devel schedule, it's unclear if it's going to land upstream in time. > > We've shipped -rc's as GA kernels before, but I always felt 'dirty' for > > doing this (especially when we name them incorrectly). > > Shipping it with 'rc3' or whatever in the title seems a little more > > honest at least about what we're shipping, and at the same time, > > it prevents bad reviewers from writing "Fedora still ships with a 2.6.22 > > kernel". > > Sort of related to this - it's (usually? often?) the case that the > shipped kernel is based on a "stable" point release - eg. on this F-7 > box, the kernel is based on 2.6.21.2 according to the %changelog, and > yet the kernel rpm is kernel-2.6.21-1.3228. Would it not be sensible > to also add that last point number? Sounds sensible. I did try a long time ago (when 2.6.x.y first began) and it broke something which I now forget, but it's probably something that just needs a bit more thought. > ps. Sorry to Dave for sending this mail to him alone rather than the list > pps. Why does this list not set the Reply-To to the list rather than > the message sender? http://www.unicom.com/pw/reply-to-harmful.html Dave -- http://www.codemonkey.org.uk From jwilson at redhat.com Mon Jul 2 17:50:21 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Mon, 02 Jul 2007 13:50:21 -0400 Subject: spec hacks for vanilla and git-based kernel rpm builds In-Reply-To: <20070702173957.GA6403@redhat.com> References: <20070608203730.BF4E84D05A0@magilla.localdomain> <46891EE6.1060402@redhat.com> <20070702155719.GC729@redhat.com> <1183392059.16523.22.camel@weaponx.rchland.ibm.com> <20070702162719.GA24863@redhat.com> <46893575.60105@leemhuis.info> <20070702173957.GA6403@redhat.com> Message-ID: <46893ADD.6040203@redhat.com> Dave Jones wrote: > On Mon, Jul 02, 2007 at 07:27:17PM +0200, Thorsten Leemhuis wrote: > > > > Shipping it with 'rc3' or whatever in the title seems a little more > > > honest at least about what we're shipping, and at the same time, > > > it prevents bad reviewers from writing "Fedora still ships with a 2.6.22 > > > kernel". > > > > A proper kernel naming would help there as well (e.g. name the kernels > > just as upstream -- e.g. 2.6.23-rc[1-7]{,.git[0-9]*). ;-) Yeah, this old > > topic again that never got solved. > > Indeed. That's what Jarod was proposing to fix no? Well, initially, I was thinking only for the vanilla variant to start out, but screw it, I'll go whole hog. Working on it now... -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From fedora at leemhuis.info Mon Jul 2 17:51:23 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 02 Jul 2007 19:51:23 +0200 Subject: spec hacks for vanilla and git-based kernel rpm builds In-Reply-To: <20070702173957.GA6403@redhat.com> References: <20070608203730.BF4E84D05A0@magilla.localdomain> <46891EE6.1060402@redhat.com> <20070702155719.GC729@redhat.com> <1183392059.16523.22.camel@weaponx.rchland.ibm.com> <20070702162719.GA24863@redhat.com> <46893575.60105@leemhuis.info> <20070702173957.GA6403@redhat.com> Message-ID: <46893B1B.1010809@leemhuis.info> On 02.07.2007 19:39, Dave Jones wrote: > On Mon, Jul 02, 2007 at 07:27:17PM +0200, Thorsten Leemhuis wrote: > > > I'd still really like us to ship 2.6.23 for f8, but with the shorter > > > devel schedule, it's unclear if it's going to land upstream in time. > > > We've shipped -rc's as GA kernels before, but I always felt 'dirty' for > > > doing this (especially when we name them incorrectly). > > > > I'd say it's unlikely that 2.6.23 is not ready in time for F8. Some > > statistics that lead to my opinion: > > > > 2.6.18 took 94 days to develop > > 2.6.19 took 71 days > > 2.6.20 took 66 days > > 2.6.21 took 80 days > > > > 2.6.22 is about 5-7 days away afaics; so it will have had around 73 days > > to get finished. > > > > Final devel freeze for F8 currently is 24 October 2007 -- that's 114 > > days away from now; minus those ~6 days until 2.6.22; that leaves around > > 108 days for 2.6.23 to mature in time for the F8 freeze. I'd say that > > should work out when I look at the numbers from recent kernels found above. > The concerns I have is that summertime is usually a slower period. > People go to conferences, summits, beaches a lot more, so it could > drag out a little. You have a point there -- just look at the numbers from 2.6.18 above (2.6.17 was 18.06.2006) and one ca see that 2.6.18 took a bit longer. But anyway: > But based on your numbers, there is quite a bit > of room for lag in there, so it's still plausible that we'll make > it by October. +1 > > > Shipping it with 'rc3' or whatever in the title seems a little more > > > honest at least about what we're shipping, and at the same time, > > > it prevents bad reviewers from writing "Fedora still ships with a 2.6.22 > > > kernel". > > A proper kernel naming would help there as well (e.g. name the kernels > > just as upstream -- e.g. 2.6.23-rc[1-7]{,.git[0-9]*). ;-) Yeah, this old > > topic again that never got solved. > Indeed. That's what Jarod was proposing to fix no? /me reads thread again Yeah, missed that, sorry. Cu thl From davej at redhat.com Mon Jul 2 18:11:07 2007 From: davej at redhat.com (Dave Jones) Date: Mon, 2 Jul 2007 14:11:07 -0400 Subject: spec hacks for vanilla and git-based kernel rpm builds In-Reply-To: <46893B1B.1010809@leemhuis.info> References: <20070608203730.BF4E84D05A0@magilla.localdomain> <46891EE6.1060402@redhat.com> <20070702155719.GC729@redhat.com> <1183392059.16523.22.camel@weaponx.rchland.ibm.com> <20070702162719.GA24863@redhat.com> <46893575.60105@leemhuis.info> <20070702173957.GA6403@redhat.com> <46893B1B.1010809@leemhuis.info> Message-ID: <20070702181107.GC6403@redhat.com> On Mon, Jul 02, 2007 at 07:51:23PM +0200, Thorsten Leemhuis wrote: > > > 2.6.22 is about 5-7 days away afaics; so it will have had around 73 days > > > to get finished. > > > > > > Final devel freeze for F8 currently is 24 October 2007 -- that's 114 > > > days away from now; minus those ~6 days until 2.6.22; that leaves around > > > 108 days for 2.6.23 to mature in time for the F8 freeze. I'd say that > > > should work out when I look at the numbers from recent kernels found above. > > The concerns I have is that summertime is usually a slower period. > > People go to conferences, summits, beaches a lot more, so it could > > drag out a little. > > You have a point there -- just look at the numbers from 2.6.18 above > (2.6.17 was 18.06.2006) and one ca see that 2.6.18 took a bit longer. > But anyway: actually, Red Hat was at least partly responsible for why .18 dragged out a bit too. When Linus & Andrew found out we were going to base RHEL5 on it, they wanted to be sure that the final .18 on which we built was fairly solid. During -rc for that kernel quite a few nasty long-drawn out bugs were found and fixed iirc. Dave -- http://www.codemonkey.org.uk From roland at redhat.com Mon Jul 2 20:07:46 2007 From: roland at redhat.com (Roland McGrath) Date: Mon, 2 Jul 2007 13:07:46 -0700 (PDT) Subject: spec hacks for vanilla and git-based kernel rpm builds In-Reply-To: Jarod Wilson's message of Monday, 2 July 2007 11:51:02 -0400 <46891EE6.1060402@redhat.com> Message-ID: <20070702200746.8B7444D0571@magilla.localdomain> > So I finally got around to poking at these bits again myself (in > relation to bug 240878), but ran into an issue with a vanilla/nopatches > build: > > $ rpmbuild -bb --with baseonly --define 'nopatches 1' kernel-2.6.spec > RPM build errors: > File not found: > /data/buildroot/tmp/kernel-2.6.21-1.3243.fc8-root-x86_64/usr/src/debug/kernel-vanilla-2.6.21/linux-2.6.21.x86_64 > > There exists a .../debug/kernel-2.6.21/linux-2.6.21.x86_64 though. > (Looking into it more now, but figured I'd throw it out there, in case > someone already knows what's up). Hmm. There are various magic things that use %{name} and others that use "kernel" explicitly. I'm sure this worked when I checked the stuff in. So something must have changed. I had to tweak something or other because of this issue, probably the %setup -n arg, but I don't quite recall. I made it use plain kernel-%{version} for the source dir name mostly so that an rpmbuild in your working dir reuses the kernel-V/vanilla dir and links. For having both installed in debuginfo rpms, it might make more sense to let it all use %{name}. > Also, anyone have thoughts on re-versioning, at least in the vanilla > case, so as to more accurately describe what's being built? For example, > the above is 2.6.22-rc4-git6, so I'm a fan of the package that gets > churned out being kernel-vanilla-2.6.22-0.1.rc4.git6.fc8 or some such > thing, instead of kernel-vanilla-2.6.21-1.3243.fc8. My gen-patches script used for the git-based rpms does something vaguely like this based on: git describe | sed 's/-g[0-9a-f]*$//;s/-/./g;s/^v//'. The -gitN names are not actual tags so git tools don't tell you about them, but the newfangled git-describe "number of commits since" version number makes for something that increases and can be resolved into an upstream rev. From jwilson at redhat.com Mon Jul 2 20:22:24 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Mon, 02 Jul 2007 16:22:24 -0400 Subject: Kernel rpm versioning changes Message-ID: <46895E80.5070500@redhat.com> Okay, here's the first draft of spec changes to alter the kernel rpm version and release fields to more closely match what the actual upstream kernel base is. Its heavily commented at the moment to try to explain what's going on. The basic approach is this: 1st fedora build of 2.6.21.5: kernel-2.6.21.5-1.fc7 2nd fedora build of 2.6.21.5: kernel-2.6.21.5-2.fc7 1st fedora build of 2.6.22-rc6-git3: kernel-2.6.22-0.rc6.git3.1.fc8 2nd fedora build of 2.6.22-rc7: kernel-2.6.22-0.rc7.2.fc8 ...and so on. Added bonus on rc/git builds: you set the rc and git revisions near the top of the spec, and the needed patches are automagically generated in the right place. At least from spectool's point of view, I've got this working perfectly from the generated n-v-r standpoint for all of the above combos and then some. A test build of kernel-2.6.22-0.rc7.1.fc8 just finished building with one error, which I've traced the source of -- debug files come from the source tree, which is still versioned with the base kernel version. This should be fixed in the attached diff, but the build is still underway to verify that. Regardless of that, I'd like some feedback before going much further down the current path. Everything between "hey, that looks good!" and "what in the blue hell are you thinking?" welcomed. :) (Even better if you have suggestions for improvement). -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: kernel-versioning-changes.diff Type: text/x-patch Size: 6767 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From roland at redhat.com Mon Jul 2 20:29:17 2007 From: roland at redhat.com (Roland McGrath) Date: Mon, 2 Jul 2007 13:29:17 -0700 (PDT) Subject: Kernel rpm versioning changes In-Reply-To: Jarod Wilson's message of Monday, 2 July 2007 16:22:24 -0400 <46895E80.5070500@redhat.com> Message-ID: <20070702202917.222A14D03E5@magilla.localdomain> I think this is what will fix the kernel-vanilla-debuginfo-common problem. --- kernel-2.6.spec 2 Jul 2007 17:07:41 -0000 1.3245 +++ kernel-2.6.spec 2 Jul 2007 20:28:13 -0000 @@ -1473,10 +1477,10 @@ BuildKernel %make_target %kernel_image k %global __debug_package 1 %files debuginfo-common %defattr(-,root,root) -/usr/src/debug/%{name}-%{version}/linux-%{kversion}.%{_target_cpu} +/usr/src/debug/kernel-%{version}/linux-%{kversion}.%{_target_cpu} %if %{includexen} %if %{with_xen} -/usr/src/debug/%{name}-%{version}/xen +/usr/src/debug/kernel-%{version}/xen %endif %endif %dir /usr/src/debug From roland at redhat.com Mon Jul 2 20:34:15 2007 From: roland at redhat.com (Roland McGrath) Date: Mon, 2 Jul 2007 13:34:15 -0700 (PDT) Subject: Kernel rpm versioning changes In-Reply-To: Jarod Wilson's message of Monday, 2 July 2007 16:22:24 -0400 <46895E80.5070500@redhat.com> Message-ID: <20070702203415.873F04D03E5@magilla.localdomain> What about before the first -rcN tag? From jwilson at redhat.com Mon Jul 2 20:40:06 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Mon, 02 Jul 2007 16:40:06 -0400 Subject: spec hacks for vanilla and git-based kernel rpm builds In-Reply-To: <20070702200746.8B7444D0571@magilla.localdomain> References: <20070702200746.8B7444D0571@magilla.localdomain> Message-ID: <468962A6.8050505@redhat.com> Roland McGrath wrote: >> So I finally got around to poking at these bits again myself (in >> relation to bug 240878), but ran into an issue with a vanilla/nopatches >> build: >> >> $ rpmbuild -bb --with baseonly --define 'nopatches 1' kernel-2.6.spec >> RPM build errors: >> File not found: >> /data/buildroot/tmp/kernel-2.6.21-1.3243.fc8-root-x86_64/usr/src/debug/kernel-vanilla-2.6.21/linux-2.6.21.x86_64 >> >> There exists a .../debug/kernel-2.6.21/linux-2.6.21.x86_64 though. >> (Looking into it more now, but figured I'd throw it out there, in case >> someone already knows what's up). > > Hmm. There are various magic things that use %{name} and others that use > "kernel" explicitly. I'm sure this worked when I checked the stuff in. So > something must have changed. I had to tweak something or other because of > this issue, probably the %setup -n arg, but I don't quite recall. I made > it use plain kernel-%{version} for the source dir name mostly so that an > rpmbuild in your working dir reuses the kernel-V/vanilla dir and links. > For having both installed in debuginfo rpms, it might make more sense to > let it all use %{name}. It looks like all the debug stuff is in a directory structure that matches whatever resulted from %setup, and the %files section references them using %{name}, but needs to use "kernel" instead of %{name}. >> Also, anyone have thoughts on re-versioning, at least in the vanilla >> case, so as to more accurately describe what's being built? For example, >> the above is 2.6.22-rc4-git6, so I'm a fan of the package that gets >> churned out being kernel-vanilla-2.6.22-0.1.rc4.git6.fc8 or some such >> thing, instead of kernel-vanilla-2.6.21-1.3243.fc8. > > My gen-patches script used for the git-based rpms does something vaguely > like this based on: git describe | sed 's/-g[0-9a-f]*$//;s/-/./g;s/^v//'. > The -gitN names are not actual tags so git tools don't tell you about them, > but the newfangled git-describe "number of commits since" version number > makes for something that increases and can be resolved into an upstream rev. I just sent off a spec diff a few minutes ago that basically implements what I was thinking of (and now I see you've already commented on...). The main rc and git numbers I was interested in are those from the upstream Linus tree snapshots, which usually end up getting manually entered in the form of the patches added to the build, so I figured no magic necessary. The new stuff should interoperate with your bits as well for other-tree-git-based rpms too though. -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From jwilson at redhat.com Mon Jul 2 20:41:43 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Mon, 02 Jul 2007 16:41:43 -0400 Subject: Kernel rpm versioning changes In-Reply-To: <20070702202917.222A14D03E5@magilla.localdomain> References: <20070702202917.222A14D03E5@magilla.localdomain> Message-ID: <46896307.20806@redhat.com> Roland McGrath wrote: > I think this is what will fix the kernel-vanilla-debuginfo-common problem. > > --- kernel-2.6.spec 2 Jul 2007 17:07:41 -0000 1.3245 > +++ kernel-2.6.spec 2 Jul 2007 20:28:13 -0000 > @@ -1473,10 +1477,10 @@ BuildKernel %make_target %kernel_image k > %global __debug_package 1 > %files debuginfo-common > %defattr(-,root,root) > -/usr/src/debug/%{name}-%{version}/linux-%{kversion}.%{_target_cpu} > +/usr/src/debug/kernel-%{version}/linux-%{kversion}.%{_target_cpu} > %if %{includexen} > %if %{with_xen} > -/usr/src/debug/%{name}-%{version}/xen > +/usr/src/debug/kernel-%{version}/xen > %endif > %endif > %dir /usr/src/debug Yup, same conclusion I came to. -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From jwilson at redhat.com Mon Jul 2 20:58:53 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Mon, 02 Jul 2007 16:58:53 -0400 Subject: Kernel rpm versioning changes In-Reply-To: <20070702203415.873F04D03E5@magilla.localdomain> References: <20070702203415.873F04D03E5@magilla.localdomain> Message-ID: <4689670D.6070208@redhat.com> Roland McGrath wrote: > What about before the first -rcN tag? I presume you're referring to the likes of say kernel 2.6.21-gitX, which was post-2.6.21, but pre-2.6.22-rc1? Crap. Hadn't thought about that case. Okay, will have to do some further twiddling to cover that case... -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From roland at redhat.com Mon Jul 2 21:05:04 2007 From: roland at redhat.com (Roland McGrath) Date: Mon, 2 Jul 2007 14:05:04 -0700 (PDT) Subject: Kernel rpm versioning changes In-Reply-To: Jarod Wilson's message of Monday, 2 July 2007 16:58:53 -0400 <4689670D.6070208@redhat.com> Message-ID: <20070702210504.6E2204D03E5@magilla.localdomain> > I presume you're referring to the likes of say kernel 2.6.21-gitX, which > was post-2.6.21, but pre-2.6.22-rc1? Crap. Hadn't thought about that > case. Okay, will have to do some further twiddling to cover that case... Yes, that's what I meant. Faking it as "rc0" might be the easiest thing to keep the scheme's release numbers increasing. From jwilson at redhat.com Mon Jul 2 21:34:48 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Mon, 02 Jul 2007 17:34:48 -0400 Subject: Kernel rpm versioning changes In-Reply-To: <20070702210504.6E2204D03E5@magilla.localdomain> References: <20070702210504.6E2204D03E5@magilla.localdomain> Message-ID: <46896F78.8010005@redhat.com> Roland McGrath wrote: >> I presume you're referring to the likes of say kernel 2.6.21-gitX, which >> was post-2.6.21, but pre-2.6.22-rc1? Crap. Hadn't thought about that >> case. Okay, will have to do some further twiddling to cover that case... > > Yes, that's what I meant. Faking it as "rc0" might be the easiest thing to > keep the scheme's release numbers increasing. It winds up being a touch out of phase with reality, since 2.6.21-git1 ends up being called 2.6.22-rc0-git1, but the updated attached patch does account for this case now in that fashion. If we call it anything else, its out of N-V-R order. Ughlay, but still much closer than we've been, and outside of that window, it should be spot-on to see what exactly we're packaging. Oh, and this version does result in a fully-completed rpm build (also has the kernel-vanilla fix). -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: kernel-versioning-changes-v2.diff Type: text/x-patch Size: 8014 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From roland at redhat.com Mon Jul 2 21:43:46 2007 From: roland at redhat.com (Roland McGrath) Date: Mon, 2 Jul 2007 14:43:46 -0700 (PDT) Subject: Kernel rpm versioning changes In-Reply-To: Jarod Wilson's message of Monday, 2 July 2007 17:34:48 -0400 <46896F78.8010005@redhat.com> Message-ID: <20070702214346.9C54C4D047A@magilla.localdomain> What's Patch5? From jwilson at redhat.com Mon Jul 2 21:49:59 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Mon, 02 Jul 2007 17:49:59 -0400 Subject: Kernel rpm versioning changes In-Reply-To: <20070702214346.9C54C4D047A@magilla.localdomain> References: <20070702214346.9C54C4D047A@magilla.localdomain> Message-ID: <46897307.8030202@redhat.com> Roland McGrath wrote: > What's Patch5? D'oh. Meant to nuke that. Inserted for testing purposes -- 'spectool kernel-2.6.spec -p 5 -d "somemacro value"' to verify expected N-V-R's being set properly. Disregard the -v2 patch, use this guy instead. :) (or just drop the Patch5 line out of the resulting spec). -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: kernel-versioning-changes-v3.diff Type: text/x-patch Size: 7968 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 247 bytes Desc: OpenPGP digital signature URL: From davej at redhat.com Tue Jul 3 07:22:35 2007 From: davej at redhat.com (Dave Jones) Date: Tue, 3 Jul 2007 03:22:35 -0400 Subject: Fedora kernel CVS commit mails. Message-ID: <20070703072235.GA16684@redhat.com> Two possibilities.. 1. They can go to this list or 2. I can create another list for interested parties to subscribe to. Preferences? Dave -- http://www.codemonkey.org.uk From drago01 at gmail.com Tue Jul 3 07:36:45 2007 From: drago01 at gmail.com (dragoran) Date: Tue, 03 Jul 2007 09:36:45 +0200 Subject: reenable pci_msi and mmconfig by default? Message-ID: <4689FC8D.1060408@gmail.com> Can we now reenable them by default in rawhide (they should be better in .22) and see if they cause problems? From fedora at leemhuis.info Tue Jul 3 07:45:28 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 03 Jul 2007 09:45:28 +0200 Subject: Fedora kernel CVS commit mails. In-Reply-To: <20070703072235.GA16684@redhat.com> References: <20070703072235.GA16684@redhat.com> Message-ID: <4689FE98.9040708@leemhuis.info> On 03.07.2007 09:22, Dave Jones wrote: > Two possibilities.. > > 1. They can go to this list > or > 2. I can create another list for interested parties to subscribe to. > > Preferences? Where is the benefit? Isn't is sufficient to subscribe to fedora-extras-commits at redhat.com and let people filter out what you are interested in with procmail, evo or thunderbird? Further: I think with the Package DB it might soon be possible to get CCed on commits to individual packages. That might help those people that think fedora-extras-commits at redhat.com is to much traffic. CU thl From davej at redhat.com Tue Jul 3 15:06:39 2007 From: davej at redhat.com (Dave Jones) Date: Tue, 3 Jul 2007 11:06:39 -0400 Subject: Fedora kernel CVS commit mails. In-Reply-To: <4689FE98.9040708@leemhuis.info> References: <20070703072235.GA16684@redhat.com> <4689FE98.9040708@leemhuis.info> Message-ID: <20070703150639.GA6974@redhat.com> On Tue, Jul 03, 2007 at 09:45:28AM +0200, Thorsten Leemhuis wrote: > > > On 03.07.2007 09:22, Dave Jones wrote: > > Two possibilities.. > > > > 1. They can go to this list > > or > > 2. I can create another list for interested parties to subscribe to. > > > > Preferences? > > Where is the benefit? > > Isn't is sufficient to subscribe to fedora-extras-commits at redhat.com and > let people filter out what you are interested in with procmail, evo or > thunderbird? > > Further: I think with the Package DB it might soon be possible to get > CCed on commits to individual packages. That might help those people > that think fedora-extras-commits at redhat.com is to much traffic. I hadn't heard the discussion about this last point. If that works out, this all becomes moot. Dave -- http://www.codemonkey.org.uk From davej at redhat.com Tue Jul 3 15:06:56 2007 From: davej at redhat.com (Dave Jones) Date: Tue, 3 Jul 2007 11:06:56 -0400 Subject: reenable pci_msi and mmconfig by default? In-Reply-To: <4689FC8D.1060408@gmail.com> References: <4689FC8D.1060408@gmail.com> Message-ID: <20070703150656.GB6974@redhat.com> On Tue, Jul 03, 2007 at 09:36:45AM +0200, dragoran wrote: > Can we now reenable them by default in rawhide (they should be better in > .22) and see if they cause problems? They are. Dave -- http://www.codemonkey.org.uk From drago01 at gmail.com Tue Jul 3 15:08:17 2007 From: drago01 at gmail.com (dragoran) Date: Tue, 3 Jul 2007 17:08:17 +0200 Subject: reenable pci_msi and mmconfig by default? In-Reply-To: <20070703150656.GB6974@redhat.com> References: <4689FC8D.1060408@gmail.com> <20070703150656.GB6974@redhat.com> Message-ID: On 7/3/07, Dave Jones wrote: > > On Tue, Jul 03, 2007 at 09:36:45AM +0200, dragoran wrote: > > Can we now reenable them by default in rawhide (they should be better in > > .22) and see if they cause problems? > > They are. ok, needs to set up a new rawhide box soon ;) Dave > > -- > http://www.codemonkey.org.uk > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwilson at redhat.com Tue Jul 3 15:56:27 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Tue, 03 Jul 2007 11:56:27 -0400 Subject: Kernel rpm versioning changes In-Reply-To: <46897307.8030202@redhat.com> References: <20070702214346.9C54C4D047A@magilla.localdomain> <46897307.8030202@redhat.com> Message-ID: <468A71AB.2000807@redhat.com> Jarod Wilson wrote: > Roland McGrath wrote: >> What's Patch5? > > D'oh. Meant to nuke that. Inserted for testing purposes -- 'spectool > kernel-2.6.spec -p 5 -d "somemacro value"' to verify expected N-V-R's > being set properly. Disregard the -v2 patch, use this guy instead. :) > (or just drop the Patch5 line out of the resulting spec). At davej's behest, went ahead and checked this version in, and started up a build in koji. Keeping an eye on the build (http://koji.fedoraproject.org/koji/taskinfo?taskID=55435) so as to fix any possible breakage asap. One buglet with make prep already found and fixed, yell loudly if anything else crops up. Otherwise, looking good so far, koji is starting in on building binaries now... -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From davej at redhat.com Tue Jul 3 16:33:07 2007 From: davej at redhat.com (Dave Jones) Date: Tue, 3 Jul 2007 12:33:07 -0400 Subject: Kernel rpm versioning changes In-Reply-To: <468A71AB.2000807@redhat.com> References: <20070702214346.9C54C4D047A@magilla.localdomain> <46897307.8030202@redhat.com> <468A71AB.2000807@redhat.com> Message-ID: <20070703163307.GA18725@redhat.com> On Tue, Jul 03, 2007 at 11:56:27AM -0400, Jarod Wilson wrote: > Jarod Wilson wrote: > > Roland McGrath wrote: > >> What's Patch5? > > > > D'oh. Meant to nuke that. Inserted for testing purposes -- 'spectool > > kernel-2.6.spec -p 5 -d "somemacro value"' to verify expected N-V-R's > > being set properly. Disregard the -v2 patch, use this guy instead. :) > > (or just drop the Patch5 line out of the resulting spec). > > At davej's behest, went ahead and checked this version in, and started > up a build in koji. Keeping an eye on the build > (http://koji.fedoraproject.org/koji/taskinfo?taskID=55435) so as to fix > any possible breakage asap. One buglet with make prep already found and > fixed, yell loudly if anything else crops up. > > Otherwise, looking good so far, koji is starting in on building binaries > now... Ick... $ rpmvercmp kernel-2.6.22-0.rc7.git1.2.fc8 kernel-2.6.22-0.rc7.2.fc8 name: kernel = kernel verson: 2.6.22 = 2.6.22 release: 0.rc7.git1.2.fc8 < 0.rc7.2.fc8 kernel-2.6.22-0.rc7.git1.2.fc8 < kernel-2.6.22-0.rc7.2.fc8 Dave -- http://www.codemonkey.org.uk From tcallawa at redhat.com Tue Jul 3 16:47:18 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 03 Jul 2007 11:47:18 -0500 Subject: Kernel rpm versioning changes In-Reply-To: <20070703163307.GA18725@redhat.com> References: <20070702214346.9C54C4D047A@magilla.localdomain> <46897307.8030202@redhat.com> <468A71AB.2000807@redhat.com> <20070703163307.GA18725@redhat.com> Message-ID: <1183481238.3404.5.camel@dhcp-32-74.ord.redhat.com> On Tue, 2007-07-03 at 12:33 -0400, Dave Jones wrote: > On Tue, Jul 03, 2007 at 11:56:27AM -0400, Jarod Wilson wrote: > > Jarod Wilson wrote: > > > Roland McGrath wrote: > > >> What's Patch5? > > > > > > D'oh. Meant to nuke that. Inserted for testing purposes -- 'spectool > > > kernel-2.6.spec -p 5 -d "somemacro value"' to verify expected N-V-R's > > > being set properly. Disregard the -v2 patch, use this guy instead. :) > > > (or just drop the Patch5 line out of the resulting spec). > > > > At davej's behest, went ahead and checked this version in, and started > > up a build in koji. Keeping an eye on the build > > (http://koji.fedoraproject.org/koji/taskinfo?taskID=55435) so as to fix > > any possible breakage asap. One buglet with make prep already found and > > fixed, yell loudly if anything else crops up. > > > > Otherwise, looking good so far, koji is starting in on building binaries > > now... > > Ick... > > $ rpmvercmp kernel-2.6.22-0.rc7.git1.2.fc8 kernel-2.6.22-0.rc7.2.fc8 > name: kernel = kernel > verson: 2.6.22 = 2.6.22 > release: 0.rc7.git1.2.fc8 < 0.rc7.2.fc8 > kernel-2.6.22-0.rc7.git1.2.fc8 < kernel-2.6.22-0.rc7.2.fc8 This is why Fedora adopted the pre-release versioning scheme that we did: http://fedoraproject.org/wiki/Packaging/NamingGuidelines#PreReleasePackages In the Fedora scheme, this would be 0.%{X}.%{alphatag} Or, in your specific example: kernel-2.6.22-0.2.rc7.git1.fc8 vs kernel-2.6.22-0.1.rc7.fc8 [root at dhcp-32-74 ~]# /usr/bin/fedora-rpmvercmp Epoch1 :0 Version1 :2.6.22 Release1 :0.2.rc7.git1.fc8 Epoch2 :0 Version2 :2.6.22 Release2 :0.1.rc7.fc8 0:2.6.22-0.2.rc7.git1.fc8 is newer Note that for this to work, you need to increment %{X} upon every new package. ~spot From davej at redhat.com Tue Jul 3 18:47:32 2007 From: davej at redhat.com (Dave Jones) Date: Tue, 3 Jul 2007 14:47:32 -0400 Subject: Kernel rpm versioning changes In-Reply-To: <1183481238.3404.5.camel@dhcp-32-74.ord.redhat.com> References: <20070702214346.9C54C4D047A@magilla.localdomain> <46897307.8030202@redhat.com> <468A71AB.2000807@redhat.com> <20070703163307.GA18725@redhat.com> <1183481238.3404.5.camel@dhcp-32-74.ord.redhat.com> Message-ID: <20070703184732.GB4167@redhat.com> On Tue, Jul 03, 2007 at 11:47:18AM -0500, Tom spot Callaway wrote: > This is why Fedora adopted the pre-release versioning scheme that we > did: > > http://fedoraproject.org/wiki/Packaging/NamingGuidelines#PreReleasePackages > > In the Fedora scheme, this would be > > 0.%{X}.%{alphatag} > > Or, in your specific example: > > kernel-2.6.22-0.2.rc7.git1.fc8 vs kernel-2.6.22-0.1.rc7.fc8 Ok, that looks fixable by doing this.. Jarod, want to give this a quick once-over? Index: kernel-2.6.spec =================================================================== RCS file: /cvs/pkgs/rpms/kernel/devel/kernel-2.6.spec,v retrieving revision 1.3257 diff -u -p -r1.3257 kernel-2.6.spec --- kernel-2.6.spec 3 Jul 2007 16:45:36 -0000 1.3257 +++ kernel-2.6.spec 3 Jul 2007 18:45:22 -0000 @@ -15,7 +15,7 @@ Summary: The Linux kernel (the core of t # fedora_build defines which build revision of this kernel version we're building. In the # non-kernel world, this is analogous to the Release: field, and is formatted similarly. -%define fedora_build 2%{?dist} +%define fedora_build 2 # base_sublevel is the kernel version we're starting with and patching # on top of -- for example, 2.6.22-rc7-git1 starts with a 2.6.21 base, @@ -107,7 +107,7 @@ Summary: The Linux kernel (the core of t # pkg_release is what we'll fill in for the rpm Release: field %if %{released_kernel} -%define pkg_release %{fedora_build}%{?buildid} +%define pkg_release %{fedora_build}%{?dist}%{?buildid} %else %if 0%{?rcrev} %define rctag .rc%rcrev @@ -118,7 +118,7 @@ Summary: The Linux kernel (the core of t %define rctag .rc0 %endif %endif -%define pkg_release 0%{?rctag}%{?gittag}.%{fedora_build}%{?buildid} +%define pkg_release 0.%{fedora_build}%{?buildid}%{?rctag}%{?gittag}%{?dist} %endif # The kernel tarball/base version > Note that for this to work, you need to increment %{X} upon every new > package. It's non-obvious to me what %{?buildid} is, but it seems to auto-increment. Dave -- http://www.codemonkey.org.uk From roland at redhat.com Tue Jul 3 18:52:00 2007 From: roland at redhat.com (Roland McGrath) Date: Tue, 3 Jul 2007 11:52:00 -0700 (PDT) Subject: Kernel rpm versioning changes In-Reply-To: Dave Jones's message of Tuesday, 3 July 2007 14:47:32 -0400 <20070703184732.GB4167@redhat.com> Message-ID: <20070703185200.A14B94D0435@magilla.localdomain> > It's non-obvious to me what %{?buildid} is, but it seems to > auto-increment. buildid is the "please set this to .me" one. fedora_build is the one to bump on commit. From ehabkost at redhat.com Tue Jul 3 18:56:45 2007 From: ehabkost at redhat.com (Eduardo Habkost) Date: Tue, 3 Jul 2007 15:56:45 -0300 Subject: Kernel rpm versioning changes In-Reply-To: <20070703185200.A14B94D0435@magilla.localdomain> References: <20070703184732.GB4167@redhat.com> <20070703185200.A14B94D0435@magilla.localdomain> Message-ID: <20070703185644.GM30287@blackpad.ctb.virtua.com.br> On Tue, Jul 03, 2007 at 11:52:00AM -0700, Roland McGrath wrote: > > It's non-obvious to me what %{?buildid} is, but it seems to > > auto-increment. > > buildid is the "please set this to .me" one. > fedora_build is the one to bump on commit. Can't %{fedora_build} be set based on the $Revision$ keyword, to be incremented automatically on commit, just like %{specrelease} was auto-incremeted previously? -- Eduardo From davej at redhat.com Tue Jul 3 19:01:01 2007 From: davej at redhat.com (Dave Jones) Date: Tue, 3 Jul 2007 15:01:01 -0400 Subject: Kernel rpm versioning changes In-Reply-To: <20070703185644.GM30287@blackpad.ctb.virtua.com.br> References: <20070703184732.GB4167@redhat.com> <20070703185200.A14B94D0435@magilla.localdomain> <20070703185644.GM30287@blackpad.ctb.virtua.com.br> Message-ID: <20070703190101.GC4167@redhat.com> On Tue, Jul 03, 2007 at 03:56:45PM -0300, Eduardo Habkost wrote: > On Tue, Jul 03, 2007 at 11:52:00AM -0700, Roland McGrath wrote: > > > It's non-obvious to me what %{?buildid} is, but it seems to > > > auto-increment. > > > > buildid is the "please set this to .me" one. > > fedora_build is the one to bump on commit. > > Can't %{fedora_build} be set based on the $Revision$ keyword, to be > incremented automatically on commit, just like %{specrelease} was > auto-incremeted previously? Yes, it can. With.. %define fedora_build %(R="$Revision: 1.3125 $"; RR="${R##: }"; echo %${RR%%?} | sed s/1\.//) Which would yield.. kernel-2.6.22-0.3125.rc7.fc8 Dave -- http://www.codemonkey.org.uk From jwilson at redhat.com Tue Jul 3 19:01:16 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Tue, 03 Jul 2007 15:01:16 -0400 Subject: Kernel rpm versioning changes In-Reply-To: <20070703184732.GB4167@redhat.com> References: <20070702214346.9C54C4D047A@magilla.localdomain> <46897307.8030202@redhat.com> <468A71AB.2000807@redhat.com> <20070703163307.GA18725@redhat.com> <1183481238.3404.5.camel@dhcp-32-74.ord.redhat.com> <20070703184732.GB4167@redhat.com> Message-ID: <468A9CFC.2020103@redhat.com> Dave Jones wrote: > On Tue, Jul 03, 2007 at 11:47:18AM -0500, Tom spot Callaway wrote: > > > This is why Fedora adopted the pre-release versioning scheme that we > > did: > > > > http://fedoraproject.org/wiki/Packaging/NamingGuidelines#PreReleasePackages > > > > In the Fedora scheme, this would be > > > > 0.%{X}.%{alphatag} > > > > Or, in your specific example: > > > > kernel-2.6.22-0.2.rc7.git1.fc8 vs kernel-2.6.22-0.1.rc7.fc8 > > Ok, that looks fixable by doing this.. Damn, I looked at that particular case and everything was just fine with it in my head... Stupid head. > Jarod, want to give this a quick once-over? Yup. > Index: kernel-2.6.spec > =================================================================== > RCS file: /cvs/pkgs/rpms/kernel/devel/kernel-2.6.spec,v > retrieving revision 1.3257 > diff -u -p -r1.3257 kernel-2.6.spec > --- kernel-2.6.spec 3 Jul 2007 16:45:36 -0000 1.3257 > +++ kernel-2.6.spec 3 Jul 2007 18:45:22 -0000 > @@ -15,7 +15,7 @@ Summary: The Linux kernel (the core of t > > # fedora_build defines which build revision of this kernel version we're building. In the > # non-kernel world, this is analogous to the Release: field, and is formatted similarly. > -%define fedora_build 2%{?dist} > +%define fedora_build 2 I might change the comment here slightly, since w/o %{?dist} right there, its not quite the same as Release: anymore, but that's neither here nor there for actually fixing the problem... :) > # base_sublevel is the kernel version we're starting with and patching > # on top of -- for example, 2.6.22-rc7-git1 starts with a 2.6.21 base, > @@ -107,7 +107,7 @@ Summary: The Linux kernel (the core of t > > # pkg_release is what we'll fill in for the rpm Release: field > %if %{released_kernel} > -%define pkg_release %{fedora_build}%{?buildid} > +%define pkg_release %{fedora_build}%{?dist}%{?buildid} > %else > %if 0%{?rcrev} > %define rctag .rc%rcrev > @@ -118,7 +118,7 @@ Summary: The Linux kernel (the core of t > %define rctag .rc0 > %endif > %endif > -%define pkg_release 0%{?rctag}%{?gittag}.%{fedora_build}%{?buildid} > +%define pkg_release 0.%{fedora_build}%{?buildid}%{?rctag}%{?gittag}%{?dist} > %endif > > # The kernel tarball/base version > > > Note that for this to work, you need to increment %{X} upon every new > > package. > > It's non-obvious to me what %{?buildid} is, but it seems to > auto-increment. The %buildid is for one-off builds, there's a blurb at the top of the spec where we request people to set it for their own custom builds for identifying non-official kernels. Never set in official fedora builds. The order of it in pkg_release probably doesn't matter too much, though I personally like it at the very end. Otherwise, the changes look fine to me. The other crazy idea I had was to call 2.6.22-rc7 2.6.22-0.rc7.git0.1.fc8. Making fedora_build auto-increment is probably cleaner, though it'd be nice to also have it reset on a kernel major version rebase (either manually or automagically). -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From ehabkost at redhat.com Tue Jul 3 19:13:55 2007 From: ehabkost at redhat.com (Eduardo Habkost) Date: Tue, 3 Jul 2007 16:13:55 -0300 Subject: Kernel rpm versioning changes In-Reply-To: <468A9CFC.2020103@redhat.com> References: <20070702214346.9C54C4D047A@magilla.localdomain> <46897307.8030202@redhat.com> <468A71AB.2000807@redhat.com> <20070703163307.GA18725@redhat.com> <1183481238.3404.5.camel@dhcp-32-74.ord.redhat.com> <20070703184732.GB4167@redhat.com> <468A9CFC.2020103@redhat.com> Message-ID: <20070703191355.GN30287@blackpad.ctb.virtua.com.br> On Tue, Jul 03, 2007 at 03:01:16PM -0400, Jarod Wilson wrote: > > The other crazy idea I had was to call 2.6.22-rc7 > 2.6.22-0.rc7.git0.1.fc8. Making fedora_build auto-increment is probably > cleaner, though it'd be nice to also have it reset on a kernel major > version rebase (either manually or automagically). I was going to propose something similar[1], but the proposal of using 0.%{fedora_build}.rc7 sounded much better to me and I dropped it before sending to the list. [1] My idea was using something like this: 2.6.22-rc7 => kernel-2.6.22-0.rc7.0.%{something else} 2.6.22-rc7-git1 => kernel-2.6.22-0.rc7.1.git1.%{something else} 2.6.22 => kernel-2.6.22-%{something else} -- Eduardo From roland at redhat.com Tue Jul 3 19:26:06 2007 From: roland at redhat.com (Roland McGrath) Date: Tue, 3 Jul 2007 12:26:06 -0700 (PDT) Subject: Kernel rpm versioning changes In-Reply-To: Dave Jones's message of Tuesday, 3 July 2007 15:01:01 -0400 <20070703190101.GC4167@redhat.com> Message-ID: <20070703192606.198E04D0435@magilla.localdomain> > On Tue, Jul 03, 2007 at 03:56:45PM -0300, Eduardo Habkost wrote: > > On Tue, Jul 03, 2007 at 11:52:00AM -0700, Roland McGrath wrote: > > > > It's non-obvious to me what %{?buildid} is, but it seems to > > > > auto-increment. > > > > > > buildid is the "please set this to .me" one. > > > fedora_build is the one to bump on commit. > > > > Can't %{fedora_build} be set based on the $Revision$ keyword, to be > > incremented automatically on commit, just like %{specrelease} was > > auto-incremeted previously? > > Yes, it can. With.. > > %define fedora_build %(R="$Revision: 1.3125 $"; RR="${R##: }"; echo %${RR%%?} | sed s/1\.//) > > Which would yield.. > > kernel-2.6.22-0.3125.rc7.fc8 %define fedora_cvs_origin 3120 %define fedora_build %(R="$Revision: 1.3125 $"; R="${R%% \$}"; R="${R##: 1.}"; expr $R - %{fedora_cvs_origin}) Change fedora_cvs_origin to current $Revision$ s/1.// when you change sublevel. From davej at redhat.com Tue Jul 3 19:32:51 2007 From: davej at redhat.com (Dave Jones) Date: Tue, 3 Jul 2007 15:32:51 -0400 Subject: Kernel rpm versioning changes In-Reply-To: <20070703192606.198E04D0435@magilla.localdomain> References: <20070703190101.GC4167@redhat.com> <20070703192606.198E04D0435@magilla.localdomain> Message-ID: <20070703193251.GE4167@redhat.com> On Tue, Jul 03, 2007 at 12:26:06PM -0700, Roland McGrath wrote: > > On Tue, Jul 03, 2007 at 03:56:45PM -0300, Eduardo Habkost wrote: > > > On Tue, Jul 03, 2007 at 11:52:00AM -0700, Roland McGrath wrote: > > > > > It's non-obvious to me what %{?buildid} is, but it seems to > > > > > auto-increment. > > > > > > > > buildid is the "please set this to .me" one. > > > > fedora_build is the one to bump on commit. > > > > > > Can't %{fedora_build} be set based on the $Revision$ keyword, to be > > > incremented automatically on commit, just like %{specrelease} was > > > auto-incremeted previously? > > > > Yes, it can. With.. > > > > %define fedora_build %(R="$Revision: 1.3125 $"; RR="${R##: }"; echo %${RR%%?} | sed s/1\.//) > > > > Which would yield.. > > > > kernel-2.6.22-0.3125.rc7.fc8 > > %define fedora_cvs_origin 3120 > %define fedora_build %(R="$Revision: 1.3125 $"; R="${R%% \$}"; R="${R##: 1.}"; expr $R - %{fedora_cvs_origin}) > > Change fedora_cvs_origin to current $Revision$ s/1.// when you change sublevel. I'm guessing the idea here is that it starts counting from 0 again each time we rebase? Sounds admirable, but it doesn't seem to work when I try it with your change. Dave -- http://www.codemonkey.org.uk From davej at redhat.com Tue Jul 3 19:35:53 2007 From: davej at redhat.com (Dave Jones) Date: Tue, 3 Jul 2007 15:35:53 -0400 Subject: Kernel rpm versioning changes In-Reply-To: <20070703193251.GE4167@redhat.com> References: <20070703190101.GC4167@redhat.com> <20070703192606.198E04D0435@magilla.localdomain> <20070703193251.GE4167@redhat.com> Message-ID: <20070703193553.GF4167@redhat.com> On Tue, Jul 03, 2007 at 03:32:51PM -0400, Dave Jones wrote: > On Tue, Jul 03, 2007 at 12:26:06PM -0700, Roland McGrath wrote: > > > On Tue, Jul 03, 2007 at 03:56:45PM -0300, Eduardo Habkost wrote: > > > > On Tue, Jul 03, 2007 at 11:52:00AM -0700, Roland McGrath wrote: > > > > > > It's non-obvious to me what %{?buildid} is, but it seems to > > > > > > auto-increment. > > > > > > > > > > buildid is the "please set this to .me" one. > > > > > fedora_build is the one to bump on commit. > > > > > > > > Can't %{fedora_build} be set based on the $Revision$ keyword, to be > > > > incremented automatically on commit, just like %{specrelease} was > > > > auto-incremeted previously? > > > > > > Yes, it can. With.. > > > > > > %define fedora_build %(R="$Revision: 1.3125 $"; RR="${R##: }"; echo %${RR%%?} | sed s/1\.//) > > > > > > Which would yield.. > > > > > > kernel-2.6.22-0.3125.rc7.fc8 > > > > %define fedora_cvs_origin 3120 > > %define fedora_build %(R="$Revision: 1.3125 $"; R="${R%% \$}"; R="${R##: 1.}"; expr $R - %{fedora_cvs_origin}) > > > > Change fedora_cvs_origin to current $Revision$ s/1.// when you change sublevel. > > I'm guessing the idea here is that it starts counting from 0 again each > time we rebase? Sounds admirable, but it doesn't seem to work when I > try it with your change. never mind, I got bitten by the 'thou shalt not comment out macros with #' bug yet again. I committed this change, thanks. Dave -- http://www.codemonkey.org.uk From jwilson at redhat.com Tue Jul 3 21:11:32 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Tue, 03 Jul 2007 17:11:32 -0400 Subject: Kernel rpm versioning changes In-Reply-To: <20070703191355.GN30287@blackpad.ctb.virtua.com.br> References: <20070702214346.9C54C4D047A@magilla.localdomain> <46897307.8030202@redhat.com> <468A71AB.2000807@redhat.com> <20070703163307.GA18725@redhat.com> <1183481238.3404.5.camel@dhcp-32-74.ord.redhat.com> <20070703184732.GB4167@redhat.com> <468A9CFC.2020103@redhat.com> <20070703191355.GN30287@blackpad.ctb.virtua.com.br> Message-ID: <468ABB84.3050004@redhat.com> > On Tue, Jul 03, 2007 at 03:01:16PM -0400, Jarod Wilson wrote: > >> The other crazy idea I had was to call 2.6.22-rc7 >> 2.6.22-0.rc7.git0.1.fc8. Making fedora_build auto-increment is probabl= y >> cleaner, though it'd be nice to also have it reset on a kernel major >> version rebase (either manually or automagically). >=20 >=20 > I was going to propose something similar[1], but the proposal of using > 0.%{fedora_build}.rc7 sounded much better to me and I dropped it > before sending to the list. >=20 >=20 > [1] My idea was using something like this: >=20 > 2.6.22-rc7 =3D> kernel-2.6.22-0.rc7.0.%{something else} > 2.6.22-rc7-git1 =3D> kernel-2.6.22-0.rc7.1.git1.%{something else} > 2.6.22 =3D> kernel-2.6.22-%{something else} >=20 Well, we've already done something to address this, but for giggles, I'll throw out one more idea that would have worked: 2.6.22-0.rc7.1.fc8 < 2.6.22-0.rc7_git2.1.fc8 But eh. What's there now worksforme, and it actually lines up better with the official fedora packaging guidelines (we'll just ignore the bazillion other things the kernel spec does that don't ;). /me heads out the door for a mini-vacation, back Saturday... --=20 Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From Axel.Thimm at ATrpms.net Wed Jul 4 09:10:40 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 4 Jul 2007 11:10:40 +0200 Subject: Kernel rpm versioning changes In-Reply-To: <46895E80.5070500@redhat.com> References: <46895E80.5070500@redhat.com> Message-ID: <20070704091040.GB14591@puariko.nirvana> On Mon, Jul 02, 2007 at 04:22:24PM -0400, Jarod Wilson wrote: > Okay, here's the first draft of spec changes to alter the kernel rpm > version and release fields to more closely match what the actual > upstream kernel base is. Its heavily commented at the moment to try to > explain what's going on. > > The basic approach is this: > > 1st fedora build of 2.6.21.5: > kernel-2.6.21.5-1.fc7 > > 2nd fedora build of 2.6.21.5: > kernel-2.6.21.5-2.fc7 > > 1st fedora build of 2.6.22-rc6-git3: > kernel-2.6.22-0.rc6.git3.1.fc8 > > 2nd fedora build of 2.6.22-rc7: > kernel-2.6.22-0.rc7.2.fc8 I'd suggest kernel-2.6.22-1.rc6.git3.fc8 kernel-2.6.22-2.rc7.fc8 an no resetting of the buildtag (the first integer) when rc6 becomes rc7 and the like o The shove-the-zero-in-front method is a method from the past when a third party would assume the vendor to start using Release tags starting with "1" and needed to make the package auto-overridable. But it makes no sense whatsoever to have the vendor himself do that ... (yes, it's part of the current guideline, but worth fixing and this could be a motivation to do so, not that many packages use non-released upstream - the kernel is the very exception here) o The buildtag doesn't mix well with the upstream extra version. "Is it rc6.git3 or rc6.git3.1?" "Are there rc7.2 upstream releases?" o indepdendence of the rpm-ordering of upstream's extra versioning, e.g. not basing the versioing scheme on facts that "git" < "rc", so "we're lucky this time"- ;) The don't-reset-buildtag-on-prereleases allows upstream to do anything they like and you're safe. o It also fits well with the non rc packaging scheme, e.g. going form git28 to rc1, then rc2.git1 etc. You just increase the buildtag and let upstream put the steam off wth any sub versioning they like. Yes, finally you'll end up with kernel-2.6.22-23.f8 That's OK, we've been in 4 figure integers already. And if someone really needs the first 2.6.22 build to be called kernel-2.6.22-1.f8, then modify the above to using "0.integer", e.g. kernel-2.6.22-0.1.rc6.git3.fc8 kernel-2.6.22-0.2.rc7.fc8 Still better to prepend the upstream's extra version part than to suffix it due to the ordering issues and the semantic mixing effects. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From feng.xian at gmail.com Mon Jul 9 22:29:49 2007 From: feng.xian at gmail.com (Feng Xian) Date: Mon, 9 Jul 2007 17:29:49 -0500 Subject: how kernel distinguish threads Message-ID: <610b3d450707091529n2ef81ab4u4df5d9cd4e71afbe@mail.gmail.com> Hi, I am working on a project about reducing page faults of multi-threaded programs. I am using latest Fedora core (Linux 2.6) and pthread library. In this project, each user-level thread (created by pthread_create() function) needs to pass a value to the task structure in the kernel which corresponds to the thread. The first step is getting a unique id of the task structure of each thread. But what is this unique id? I tried to use getpid() to get the process id of each thread and use it as unique id. But this didnt work out since all threads in a process share the same pid. I tried to use the thread_id returned by pthread_create() function but this id is meaningless to the kernel. Could anyone help me out on this? Thanks! -- Addr: 1025N, 23rd str, APT 33, Lincoln, NE, 68503 Phone: (402)310-9826 WWW: cse.unl.edu/~fxian -------------- next part -------------- An HTML attachment was scrubbed... URL: From cebbert at redhat.com Mon Jul 9 22:44:02 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Mon, 09 Jul 2007 18:44:02 -0400 Subject: how kernel distinguish threads In-Reply-To: <610b3d450707091529n2ef81ab4u4df5d9cd4e71afbe@mail.gmail.com> References: <610b3d450707091529n2ef81ab4u4df5d9cd4e71afbe@mail.gmail.com> Message-ID: <4692BA32.5040407@redhat.com> On 07/09/2007 06:29 PM, Feng Xian wrote: > Hi, I am working on a project about reducing page faults of multi-threaded > programs. I am using latest Fedora core (Linux 2.6) and pthread library. In > this project, each user-level thread (created by pthread_create() > function) > needs to pass a value to the task structure in the kernel which corresponds > to the thread. The first step is getting a unique id of the task structure > of each thread. But what is this unique id? > > I tried to use getpid() to get the process id of each thread and use it as > unique id. But this didnt work out since all threads in a process share the > same pid. I tried to use the thread_id returned by pthread_create() > function > but this id is meaningless to the kernel. Could anyone help me out on this? Use gettid() ?? From davej at redhat.com Tue Jul 10 16:47:33 2007 From: davej at redhat.com (Dave Jones) Date: Tue, 10 Jul 2007 12:47:33 -0400 Subject: 2.6.22 rebase. Message-ID: <20070710164733.GA23467@redhat.com> Last night/this morning, I've rebased FC6 and F7 CVS to 2.6.22 There are a few things worth mentioning. * I neglected to note that Xen still built from kernel/ in FC-6. kernel-xen was only F-7 aparently. As it would have likely needed decoupling anyway, I'll leave the Xen team to fix this in kernel-xen in whatever manner they see fit. * nouveau needs rebasing. Ajax? Not sure where to pull that from right now. (add url to scripts/pull-upstreams.sh) * No idea just how solid the wireless stuff is right now. I picked up whatever we had in rawhide as of yesterday, so it's "shiny and new", but for all I know that could translate to "shiny and broken". * Some of the experimental bits (like tickless), I've left enabled right now. Depending on how things look from the first round of testing will decide whether we keep it on for release. * There's a bunch of 'new bits' scheduled for .23 that we had in rawhide at the time of rebase that I feel are "ready", and make for nice bonus goodies. So there's CFS and cpuidle in there too for good measure. As always, RPMs will appear on http://people.redhat.com/davej/ periodically. (right now just F7/rawhide, but I'll see if I have enough quota to squeeze FC6 there too). When will they hit updates-testing? I anticipate we'll do a couple of builds before it goes out just to work out the really stupid bugs, but hopefully in the next few days. Dave -- http://www.codemonkey.org.uk From drago01 at gmail.com Tue Jul 10 19:48:57 2007 From: drago01 at gmail.com (dragoran) Date: Tue, 10 Jul 2007 21:48:57 +0200 Subject: 2.6.22 rebase. In-Reply-To: <20070710164733.GA23467@redhat.com> References: <20070710164733.GA23467@redhat.com> Message-ID: On 7/10/07, Dave Jones wrote: > > [...] > > * nouveau needs rebasing. Ajax? > Not sure where to pull that from right now. > (add url to scripts/pull-upstreams.sh) I might be wrong but from xorg git? git://anongit.freedesktop.org/git/nouveau/xf86-video-nouveau * No idea just how solid the wireless stuff is right now. > I picked up whatever we had in rawhide as of yesterday, > so it's "shiny and new", but for all I know that could > translate to "shiny and broken". it seems that it was broken for many people so I doubt that this will cause regressions. * Some of the experimental bits (like tickless), I've left enabled > right now. Depending on how things look from the first round > of testing will decide whether we keep it on for release. what about the x86_64 hpet issue? (or is x86_64 tickless not included yet?) * There's a bunch of 'new bits' scheduled for .23 that we had in > rawhide at the time of rebase that I feel are "ready", and make > for nice bonus goodies. So there's CFS and cpuidle in there too > for good measure. great :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From feng.xian at gmail.com Tue Jul 10 19:58:57 2007 From: feng.xian at gmail.com (Feng Xian) Date: Tue, 10 Jul 2007 14:58:57 -0500 Subject: how kernel distinguish threads In-Reply-To: <4692BA32.5040407@redhat.com> References: <610b3d450707091529n2ef81ab4u4df5d9cd4e71afbe@mail.gmail.com> <4692BA32.5040407@redhat.com> Message-ID: <610b3d450707101258m263bbddcve803a12dc4ef77b2@mail.gmail.com> Thanks. gettid() works. On 7/9/07, Chuck Ebbert < cebbert at redhat.com> wrote: > > On 07/09/2007 06:29 PM, Feng Xian wrote: > > Hi, I am working on a project about reducing page faults of > multi-threaded > > programs. I am using latest Fedora core (Linux 2.6) and pthread library. > In > > this project, each user-level thread (created by pthread_create() > > function) > > needs to pass a value to the task structure in the kernel which > corresponds > > to the thread. The first step is getting a unique id of the task > structure > > of each thread. But what is this unique id? > > > > I tried to use getpid() to get the process id of each thread and use it > as > > unique id. But this didnt work out since all threads in a process share > the > > same pid. I tried to use the thread_id returned by pthread_create() > > function > > but this id is meaningless to the kernel. Could anyone help me out on > this? > > Use gettid() ?? > > -- Addr: 1025N, 23rd str, APT 33, Lincoln, NE, 68503 Phone: (402)310-9826 WWW: cse.unl.edu/~fxian -------------- next part -------------- An HTML attachment was scrubbed... URL: From davej at redhat.com Tue Jul 10 21:34:10 2007 From: davej at redhat.com (Dave Jones) Date: Tue, 10 Jul 2007 17:34:10 -0400 Subject: 2.6.22 rebase. In-Reply-To: References: <20070710164733.GA23467@redhat.com> Message-ID: <20070710213410.GD4243@redhat.com> On Tue, Jul 10, 2007 at 09:48:57PM +0200, dragoran wrote: > * Some of the experimental bits (like tickless), I've left enabled > > right now. Depending on how things look from the first round > > of testing will decide whether we keep it on for release. > > > what about the x86_64 hpet issue? (or is x86_64 tickless not included yet?) You mean the force-enable stuff? it's disabled. Dave -- http://www.codemonkey.org.uk From ncunning at redhat.com Wed Jul 11 00:07:05 2007 From: ncunning at redhat.com (Nigel Cunningham) Date: Wed, 11 Jul 2007 10:07:05 +1000 Subject: 2.6.22 rebase. In-Reply-To: <20070710213410.GD4243@redhat.com> References: <20070710164733.GA23467@redhat.com> <20070710213410.GD4243@redhat.com> Message-ID: <200707111007.05553.ncunning@redhat.com> Hi. On Wednesday 11 July 2007 07:34:10 Dave Jones wrote: > On Tue, Jul 10, 2007 at 09:48:57PM +0200, dragoran wrote: > > > * Some of the experimental bits (like tickless), I've left enabled > > > right now. Depending on how things look from the first round > > > of testing will decide whether we keep it on for release. > > > > > > what about the x86_64 hpet issue? (or is x86_64 tickless not included yet?) No, it's not in vanilla yet, and we don't have the patch in our tree. FWIW, I'm running x86_64 tickless. I had some initial issues with hibernating and suspending, but worked them through with Thomas. It shouldn't cause any issues on that front if/when it does go in. Regards, Nigel -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From davej at redhat.com Wed Jul 11 00:53:06 2007 From: davej at redhat.com (Dave Jones) Date: Tue, 10 Jul 2007 20:53:06 -0400 Subject: 2.6.22 rebase. In-Reply-To: <200707111007.05553.ncunning@redhat.com> References: <20070710164733.GA23467@redhat.com> <20070710213410.GD4243@redhat.com> <200707111007.05553.ncunning@redhat.com> Message-ID: <20070711005306.GG4243@redhat.com> On Wed, Jul 11, 2007 at 10:07:05AM +1000, Nigel Cunningham wrote: > Hi. > > On Wednesday 11 July 2007 07:34:10 Dave Jones wrote: > > On Tue, Jul 10, 2007 at 09:48:57PM +0200, dragoran wrote: > > > > > * Some of the experimental bits (like tickless), I've left enabled > > > > right now. Depending on how things look from the first round > > > > of testing will decide whether we keep it on for release. > > > > > > > > > what about the x86_64 hpet issue? (or is x86_64 tickless not included > yet?) > > No, it's not in vanilla yet, and we don't have the patch in our tree. actually x86-64 tickless has been in rawhide about 2 weeks, and is now in this rebase for FC6/F7. Whether we roll with it for a proper update depends on how it fares during it's trial in updates-testing. So far the forced-hpet part was the only bit that's caused trouble afaics, so with that disabled, it should be (hopefully) boring. Also, Thomas is usually really on the ball at fixing up silly stuff, so if the initial cut doesn't look so good, it shouldn't be too long before we can get it back into peoples hands. > FWIW, I'm running x86_64 tickless. I had some initial issues with hibernating > and suspending, but worked them through with Thomas. It shouldn't cause any > issues on that front if/when it does go in. Once this is out there, and the worse of the fallout has been dealt with we really should try and organise some concerted effort to getting suspend/resume regressions under control, because since FC5, we've more or less just ignored those bugs due to being buried in other stuff. Dave -- http://www.codemonkey.org.uk From ncunning at redhat.com Wed Jul 11 03:50:45 2007 From: ncunning at redhat.com (Nigel Cunningham) Date: Wed, 11 Jul 2007 13:50:45 +1000 Subject: 2.6.22 rebase. In-Reply-To: <20070711005306.GG4243@redhat.com> References: <20070710164733.GA23467@redhat.com> <200707111007.05553.ncunning@redhat.com> <20070711005306.GG4243@redhat.com> Message-ID: <200707111350.45946.ncunning@redhat.com> Hi. On Wednesday 11 July 2007 10:53:06 Dave Jones wrote: > On Wed, Jul 11, 2007 at 10:07:05AM +1000, Nigel Cunningham wrote: > > Hi. > > > > On Wednesday 11 July 2007 07:34:10 Dave Jones wrote: > > > On Tue, Jul 10, 2007 at 09:48:57PM +0200, dragoran wrote: > > > > > > > * Some of the experimental bits (like tickless), I've left enabled > > > > > right now. Depending on how things look from the first round > > > > > of testing will decide whether we keep it on for release. > > > > > > > > > > > > what about the x86_64 hpet issue? (or is x86_64 tickless not included > > yet?) > > > > No, it's not in vanilla yet, and we don't have the patch in our tree. > > actually x86-64 tickless has been in rawhide about 2 weeks, and is now > in this rebase for FC6/F7. Whether we roll with it for a proper update > depends on how it fares during it's trial in updates-testing. > So far the forced-hpet part was the only bit that's caused trouble > afaics, so with that disabled, it should be (hopefully) boring. Ah. Now I see it. I was looking for 'hz', not 'hires-timers'. I haven't tried forced hpet support yet. Am I right in thinking that's only for Intels? (Mine's an AMD based Mitac). > Also, Thomas is usually really on the ball at fixing up silly stuff, so > if the initial cut doesn't look so good, it shouldn't be too long before > we can get it back into peoples hands. Yeah. He was really good to deal with when I had some interaction with him. > > FWIW, I'm running x86_64 tickless. I had some initial issues with hibernating > > and suspending, but worked them through with Thomas. It shouldn't cause any > > issues on that front if/when it does go in. > > Once this is out there, and the worse of the fallout has been dealt with > we really should try and organise some concerted effort to getting > suspend/resume regressions under control, because since FC5, we've more > or less just ignored those bugs due to being buried in other stuff. That would be good. I've been trying to get some of them dealt with, but one day a week makes it slow going. Hughsie has been having a go too, so we're making progress. Nevertheless.... Regards, Nigel -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From davej at redhat.com Wed Jul 11 04:00:50 2007 From: davej at redhat.com (Dave Jones) Date: Wed, 11 Jul 2007 00:00:50 -0400 Subject: 2.6.22 rebase. In-Reply-To: <200707111350.45946.ncunning@redhat.com> References: <20070710164733.GA23467@redhat.com> <200707111007.05553.ncunning@redhat.com> <20070711005306.GG4243@redhat.com> <200707111350.45946.ncunning@redhat.com> Message-ID: <20070711040050.GA29507@redhat.com> On Wed, Jul 11, 2007 at 01:50:45PM +1000, Nigel Cunningham wrote: > > actually x86-64 tickless has been in rawhide about 2 weeks, and is now > > in this rebase for FC6/F7. Whether we roll with it for a proper update > > depends on how it fares during it's trial in updates-testing. > > So far the forced-hpet part was the only bit that's caused trouble > > afaics, so with that disabled, it should be (hopefully) boring. > > Ah. Now I see it. I was looking for 'hz', not 'hires-timers'. I haven't tried > forced hpet support yet. Am I right in thinking that's only for Intels? > (Mine's an AMD based Mitac). So far, yes. +//DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ESB2_0, +// ich_force_enable_hpet); +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH6_1, + ich_force_enable_hpet); +//DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH7_1, +// ich_force_enable_hpet); +//DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH7_31, +// ich_force_enable_hpet); +//DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH8_1, +// ich_force_enable_hpet); however on some other chipsets, mainline already does force-enabling.. For example on my VIA EPIA ... [ 28.152336] Force enabled HPET at base address 0xfed00000 Dave -- http://www.codemonkey.org.uk From fedora at leemhuis.info Wed Jul 11 04:44:11 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 11 Jul 2007 06:44:11 +0200 Subject: 2.6.22 rebase. In-Reply-To: <20070711005306.GG4243@redhat.com> References: <20070710164733.GA23467@redhat.com> <20070710213410.GD4243@redhat.com> <200707111007.05553.ncunning@redhat.com> <20070711005306.GG4243@redhat.com> Message-ID: <4694601B.1090606@leemhuis.info> On 11.07.2007 02:53, Dave Jones wrote: > On Wed, Jul 11, 2007 at 10:07:05AM +1000, Nigel Cunningham wrote: > [...] > actually x86-64 tickless has been in rawhide about 2 weeks, and is now > in this rebase for FC6/F7. Whether we roll with it for a proper update > depends on how it fares during it's trial in updates-testing. > So far the forced-hpet part was the only bit that's caused trouble > afaics, so with that disabled, it should be (hopefully) boring. Well, for me and dragoran it's still causing trouble *afaics*; look closer at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=247346 Problems start to appear when the hpet stuff for x86_64 went it, and did not vanish when you disabled the forced-hpet for some of the recent ICH's from Intel (which afaics [would need the lspci data to be sure] are in both our machines). /me will later update the bug with the lspci output when I'm in front of my laptop again. > [...] CU thl From jwilson at redhat.com Wed Jul 11 04:55:44 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Wed, 11 Jul 2007 00:55:44 -0400 Subject: 2.6.22 rebase. In-Reply-To: <4694601B.1090606@leemhuis.info> References: <20070710164733.GA23467@redhat.com> <20070710213410.GD4243@redhat.com> <200707111007.05553.ncunning@redhat.com> <20070711005306.GG4243@redhat.com> <4694601B.1090606@leemhuis.info> Message-ID: <469462D0.2080105@redhat.com> Thorsten Leemhuis wrote: > > On 11.07.2007 02:53, Dave Jones wrote: >> On Wed, Jul 11, 2007 at 10:07:05AM +1000, Nigel Cunningham wrote: >> [...] >> actually x86-64 tickless has been in rawhide about 2 weeks, and is now >> in this rebase for FC6/F7. Whether we roll with it for a proper update >> depends on how it fares during it's trial in updates-testing. >> So far the forced-hpet part was the only bit that's caused trouble >> afaics, so with that disabled, it should be (hopefully) boring. > > Well, for me and dragoran it's still causing trouble *afaics*; look > closer at > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=247346 > > Problems start to appear when the hpet stuff for x86_64 went it, and did > not vanish when you disabled the forced-hpet for some of the recent > ICH's from Intel (which afaics [would need the lspci data to be sure] > are in both our machines). > > /me will later update the bug with the lspci output when I'm in front of > my laptop again. For the record, with 2.6.22-1.fc8 on what appears to be an ICH5 box of mine, nohpet is still required to get the thing booting. 00:00.0 Host bridge: Intel Corporation E7525 Memory Controller Hub (rev 09) 00:00.1 Class ff00: Intel Corporation E7525/E7520 Error Reporting Registers (rev 09) 00:02.0 PCI bridge: Intel Corporation E7525/E7520/E7320 PCI Express Port A (rev 09) 00:03.0 PCI bridge: Intel Corporation E7525/E7520/E7320 PCI Express Port A1 (rev 09) 00:04.0 PCI bridge: Intel Corporation E7525/E7520 PCI Express Port B (rev 09) 00:1d.0 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #1 (rev 02) 00:1d.1 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #2 (rev 02) 00:1d.2 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #3 (rev 02) 00:1d.3 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #4 (rev 02) 00:1d.7 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB2 EHCI Controller (rev 02) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev c2) 00:1f.0 ISA bridge: Intel Corporation 82801EB/ER (ICH5/ICH5R) LPC Interface Bridge (rev 02) 00:1f.1 IDE interface: Intel Corporation 82801EB/ER (ICH5/ICH5R) IDE Controller (rev 02) 00:1f.2 IDE interface: Intel Corporation 82801EB (ICH5) SATA Controller (rev 02) 00:1f.3 SMBus: Intel Corporation 82801EB/ER (ICH5/ICH5R) SMBus Controller (rev 02) 00:1f.5 Multimedia audio controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) AC'97 Audio Controller (rev 02) 01:00.0 PCI bridge: Intel Corporation 6700PXH PCI Express-to-PCI Bridge A 01:00.2 PCI bridge: Intel Corporation 6700PXH PCI Express-to-PCI Bridge B 03:0e.0 Ethernet controller: Intel Corporation 82545GM Gigabit Ethernet Controller (rev 04) 05:00.0 VGA compatible controller: nVidia Corporation NV37GL [Quadro PCI-E Series] (rev a2) Apologies for the icky line wrapping. -- Jarod Wilson jwilson at redhat.com From davej at redhat.com Wed Jul 11 05:23:53 2007 From: davej at redhat.com (Dave Jones) Date: Wed, 11 Jul 2007 01:23:53 -0400 Subject: 2.6.22 rebase. In-Reply-To: <4694601B.1090606@leemhuis.info> References: <20070710164733.GA23467@redhat.com> <20070710213410.GD4243@redhat.com> <200707111007.05553.ncunning@redhat.com> <20070711005306.GG4243@redhat.com> <4694601B.1090606@leemhuis.info> Message-ID: <20070711052353.GF4059@redhat.com> On Wed, Jul 11, 2007 at 06:44:11AM +0200, Thorsten Leemhuis wrote: > > > On 11.07.2007 02:53, Dave Jones wrote: > > On Wed, Jul 11, 2007 at 10:07:05AM +1000, Nigel Cunningham wrote: > > [...] > > actually x86-64 tickless has been in rawhide about 2 weeks, and is now > > in this rebase for FC6/F7. Whether we roll with it for a proper update > > depends on how it fares during it's trial in updates-testing. > > So far the forced-hpet part was the only bit that's caused trouble > > afaics, so with that disabled, it should be (hopefully) boring. > > Well, for me and dragoran it's still causing trouble *afaics*; look > closer at > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=247346 > > Problems start to appear when the hpet stuff for x86_64 went it, and did > not vanish when you disabled the forced-hpet for some of the recent > ICH's from Intel (which afaics [would need the lspci data to be sure] > are in both our machines). > > /me will later update the bug with the lspci output when I'm in front of > my laptop again. Yeah, I'm picking over that bug now. Will try and find a box I can reproduce this on tomorrow. Dave -- http://www.codemonkey.org.uk From jwilson at redhat.com Wed Jul 11 13:05:33 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Wed, 11 Jul 2007 09:05:33 -0400 Subject: 2.6.22 rebase. In-Reply-To: <20070711052353.GF4059@redhat.com> References: <20070710164733.GA23467@redhat.com> <20070710213410.GD4243@redhat.com> <200707111007.05553.ncunning@redhat.com> <20070711005306.GG4243@redhat.com> <4694601B.1090606@leemhuis.info> <20070711052353.GF4059@redhat.com> Message-ID: <4694D59D.2070502@redhat.com> Dave Jones wrote: > On Wed, Jul 11, 2007 at 06:44:11AM +0200, Thorsten Leemhuis wrote: > > > > > > On 11.07.2007 02:53, Dave Jones wrote: > > > On Wed, Jul 11, 2007 at 10:07:05AM +1000, Nigel Cunningham wrote: > > > [...] > > > actually x86-64 tickless has been in rawhide about 2 weeks, and is now > > > in this rebase for FC6/F7. Whether we roll with it for a proper update > > > depends on how it fares during it's trial in updates-testing. > > > So far the forced-hpet part was the only bit that's caused trouble > > > afaics, so with that disabled, it should be (hopefully) boring. > > > > Well, for me and dragoran it's still causing trouble *afaics*; look > > closer at > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=247346 > > > > Problems start to appear when the hpet stuff for x86_64 went it, and did > > not vanish when you disabled the forced-hpet for some of the recent > > ICH's from Intel (which afaics [would need the lspci data to be sure] > > are in both our machines). > > > > /me will later update the bug with the lspci output when I'm in front of > > my laptop again. > > Yeah, I'm picking over that bug now. Will try and find a box I can > reproduce this on tomorrow. I've got yer reproducer right here: dhcp83-31.boston.redhat.com, which is a Dell Precision 470 workstation w/an ICH5 chipset. -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From cebbert at redhat.com Wed Jul 11 14:45:13 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Wed, 11 Jul 2007 10:45:13 -0400 Subject: 2.6.22 rebase. In-Reply-To: <20070711052353.GF4059@redhat.com> References: <20070710164733.GA23467@redhat.com> <20070710213410.GD4243@redhat.com> <200707111007.05553.ncunning@redhat.com> <20070711005306.GG4243@redhat.com> <4694601B.1090606@leemhuis.info> <20070711052353.GF4059@redhat.com> Message-ID: <4694ECF9.3090702@redhat.com> On 07/11/2007 01:23 AM, Dave Jones wrote: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=247346 > > > > Problems start to appear when the hpet stuff for x86_64 went it, and did > > not vanish when you disabled the forced-hpet for some of the recent > > ICH's from Intel (which afaics [would need the lspci data to be sure] > > are in both our machines). > > > > /me will later update the bug with the lspci output when I'm in front of > > my laptop again. > > Yeah, I'm picking over that bug now. Will try and find a box I can > reproduce this on tomorrow. The Fedora 6 kernel doesn't boot either, at least on a Dell Workstation 490, without "nohpet". AND it requires a version of mkinitrd (6.something) that's not available for Fedora 6. (I installed with --nodeps and it seems okay but there's no 'symvers' file in /boot/grub for the new kernel.) From davej at redhat.com Wed Jul 11 16:25:45 2007 From: davej at redhat.com (Dave Jones) Date: Wed, 11 Jul 2007 12:25:45 -0400 Subject: 2.6.22 rebase. In-Reply-To: <4694ECF9.3090702@redhat.com> References: <20070710164733.GA23467@redhat.com> <20070710213410.GD4243@redhat.com> <200707111007.05553.ncunning@redhat.com> <20070711005306.GG4243@redhat.com> <4694601B.1090606@leemhuis.info> <20070711052353.GF4059@redhat.com> <4694ECF9.3090702@redhat.com> Message-ID: <20070711162545.GC15688@redhat.com> On Wed, Jul 11, 2007 at 10:45:13AM -0400, Chuck Ebbert wrote: > On 07/11/2007 01:23 AM, Dave Jones wrote: > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=247346 > > > > > > Problems start to appear when the hpet stuff for x86_64 went it, and did > > > not vanish when you disabled the forced-hpet for some of the recent > > > ICH's from Intel (which afaics [would need the lspci data to be sure] > > > are in both our machines). > > > > > > /me will later update the bug with the lspci output when I'm in front of > > > my laptop again. > > > > Yeah, I'm picking over that bug now. Will try and find a box I can > > reproduce this on tomorrow. > > The Fedora 6 kernel doesn't boot either, at least on a Dell Workstation > 490, without "nohpet". Lets just drop the 64bit tickless stuff for now, it clearly isn't baked, and isn't going to get much better by the end of the week (which I want to get something into updates-testing by). > AND it requires a version of mkinitrd (6.something) that's not available > for Fedora 6. (I installed with --nodeps and it seems okay but there's > no 'symvers' file in /boot/grub for the new kernel.) Oops, that part of the specfile update needs fixing. The require: in F6 went too far forward, and I probably pushed F7 back a rev. Dave -- http://www.codemonkey.org.uk From fedora at leemhuis.info Wed Jul 11 16:26:26 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 11 Jul 2007 18:26:26 +0200 Subject: cpuspeed und cpuidle (was: Re: 2.6.22 rebase.) In-Reply-To: <20070710164733.GA23467@redhat.com> References: <20070710164733.GA23467@redhat.com> Message-ID: <469504B2.8090605@leemhuis.info> On 10.07.2007 18:47, Dave Jones wrote: > Last night/this morning, I've rebased FC6 and F7 CVS to 2.6.22 > There are a few things worth mentioning. > [...] > * There's a bunch of 'new bits' scheduled for .23 that we had in > rawhide at the time of rebase that I feel are "ready", and make > for nice bonus goodies. So there's CFS and cpuidle in there too > for good measure. Cpuspeed afaics needs an adjustment if cpuidle stays: $ LC_ALL=C sudo /etc/init.d/cpuspeed restart Disabling ondemand cpu frequency scaling: /etc/init.d/cpuspeed: line 212: /sys/devices/system/cpu/cpuidle/cpufreq/scaling_governor: No such file or directory /etc/init.d/cpuspeed: line 213: /sys/devices/system/cpu/cpuidle/cpufreq/scaling_setspeed: No such file or directory [ OK ] /etc/init.d/cpuspeed: line 62: /sys/devices/system/cpu/cpuidle/cpufreq/scaling_governor: No such file or directory Enabling ondemand cpu frequency scaling: [ OK ] $ uname -r 2.6.22-2.fc7 $ rpm -q fedora-release fedora-release-7-3 $ Cu knurd From davej at redhat.com Wed Jul 11 16:32:58 2007 From: davej at redhat.com (Dave Jones) Date: Wed, 11 Jul 2007 12:32:58 -0400 Subject: cpuspeed und cpuidle (was: Re: 2.6.22 rebase.) In-Reply-To: <469504B2.8090605@leemhuis.info> References: <20070710164733.GA23467@redhat.com> <469504B2.8090605@leemhuis.info> Message-ID: <20070711163258.GE15688@redhat.com> On Wed, Jul 11, 2007 at 06:26:26PM +0200, Thorsten Leemhuis wrote: > > > On 10.07.2007 18:47, Dave Jones wrote: > > Last night/this morning, I've rebased FC6 and F7 CVS to 2.6.22 > > There are a few things worth mentioning. > > [...] > > * There's a bunch of 'new bits' scheduled for .23 that we had in > > rawhide at the time of rebase that I feel are "ready", and make > > for nice bonus goodies. So there's CFS and cpuidle in there too > > for good measure. > > Cpuspeed afaics needs an adjustment if cpuidle stays: > > $ LC_ALL=C sudo /etc/init.d/cpuspeed restart > Disabling ondemand cpu frequency scaling: /etc/init.d/cpuspeed: line 212: /sys/devices/system/cpu/cpuidle/cpufreq/scaling_governor: No such file or directory > /etc/init.d/cpuspeed: line 213: /sys/devices/system/cpu/cpuidle/cpufreq/scaling_setspeed: No such file or directory > [ OK ] > /etc/init.d/cpuspeed: line 62: /sys/devices/system/cpu/cpuidle/cpufreq/scaling_governor: No such file or directory > Enabling ondemand cpu frequency scaling: [ OK ] Jarod checked a fix in a day or so ago, might be working its way through koji somewhere. Dave -- http://www.codemonkey.org.uk From jwilson at redhat.com Wed Jul 11 16:35:45 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Wed, 11 Jul 2007 12:35:45 -0400 Subject: cpuspeed und cpuidle In-Reply-To: <20070711163258.GE15688@redhat.com> References: <20070710164733.GA23467@redhat.com> <469504B2.8090605@leemhuis.info> <20070711163258.GE15688@redhat.com> Message-ID: <469506E1.3000808@redhat.com> Dave Jones wrote: > On Wed, Jul 11, 2007 at 06:26:26PM +0200, Thorsten Leemhuis wrote: > > > > > > On 10.07.2007 18:47, Dave Jones wrote: > > > Last night/this morning, I've rebased FC6 and F7 CVS to 2.6.22 > > > There are a few things worth mentioning. > > > [...] > > > * There's a bunch of 'new bits' scheduled for .23 that we had in > > > rawhide at the time of rebase that I feel are "ready", and make > > > for nice bonus goodies. So there's CFS and cpuidle in there too > > > for good measure. > > > > Cpuspeed afaics needs an adjustment if cpuidle stays: > > > > $ LC_ALL=C sudo /etc/init.d/cpuspeed restart > > Disabling ondemand cpu frequency scaling: /etc/init.d/cpuspeed: line 212: /sys/devices/system/cpu/cpuidle/cpufreq/scaling_governor: No such file or directory > > /etc/init.d/cpuspeed: line 213: /sys/devices/system/cpu/cpuidle/cpufreq/scaling_setspeed: No such file or directory > > [ OK ] > > /etc/init.d/cpuspeed: line 62: /sys/devices/system/cpu/cpuidle/cpufreq/scaling_governor: No such file or directory > > Enabling ondemand cpu frequency scaling: [ OK ] > > Jarod checked a fix in a day or so ago, might be working its way through > koji somewhere. Yep, it was sitting for a day or two waiting for someone to notice my bodhi push request. It just got pushed over to stable updates a few hours ago. -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From cebbert at redhat.com Wed Jul 11 16:40:01 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Wed, 11 Jul 2007 12:40:01 -0400 Subject: cpuspeed und cpuidle In-Reply-To: <469506E1.3000808@redhat.com> References: <20070710164733.GA23467@redhat.com> <469504B2.8090605@leemhuis.info> <20070711163258.GE15688@redhat.com> <469506E1.3000808@redhat.com> Message-ID: <469507E1.7040508@redhat.com> On 07/11/2007 12:35 PM, Jarod Wilson wrote: >> > Cpuspeed afaics needs an adjustment if cpuidle stays: >> > >> > $ LC_ALL=C sudo /etc/init.d/cpuspeed restart >> > Disabling ondemand cpu frequency scaling: /etc/init.d/cpuspeed: line 212: /sys/devices/system/cpu/cpuidle/cpufreq/scaling_governor: No such file or directory >> > /etc/init.d/cpuspeed: line 213: /sys/devices/system/cpu/cpuidle/cpufreq/scaling_setspeed: No such file or directory >> > [ OK ] >> > /etc/init.d/cpuspeed: line 62: /sys/devices/system/cpu/cpuidle/cpufreq/scaling_governor: No such file or directory >> > Enabling ondemand cpu frequency scaling: [ OK ] >> >> Jarod checked a fix in a day or so ago, might be working its way through >> koji somewhere. > > Yep, it was sitting for a day or two waiting for someone to notice my > bodhi push request. It just got pushed over to stable updates a few > hours ago. Fedora 6 too? From fedora at leemhuis.info Wed Jul 11 16:44:58 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 11 Jul 2007 18:44:58 +0200 Subject: cpuspeed und cpuidle In-Reply-To: <469506E1.3000808@redhat.com> References: <20070710164733.GA23467@redhat.com> <469504B2.8090605@leemhuis.info> <20070711163258.GE15688@redhat.com> <469506E1.3000808@redhat.com> Message-ID: <4695090A.4010604@leemhuis.info> On 11.07.2007 18:35, Jarod Wilson wrote: > Dave Jones wrote: >> On Wed, Jul 11, 2007 at 06:26:26PM +0200, Thorsten Leemhuis wrote: >> > >> > >> > On 10.07.2007 18:47, Dave Jones wrote: >> > > Last night/this morning, I've rebased FC6 and F7 CVS to 2.6.22 >> > > There are a few things worth mentioning. >> > > [...] >> > > * There's a bunch of 'new bits' scheduled for .23 that we had in >> > > rawhide at the time of rebase that I feel are "ready", and make >> > > for nice bonus goodies. So there's CFS and cpuidle in there too >> > > for good measure. >> > >> > Cpuspeed afaics needs an adjustment if cpuidle stays: >> > >> > $ LC_ALL=C sudo /etc/init.d/cpuspeed restart >> > Disabling ondemand cpu frequency scaling: /etc/init.d/cpuspeed: line 212: /sys/devices/system/cpu/cpuidle/cpufreq/scaling_governor: No such file or directory >> > /etc/init.d/cpuspeed: line 213: /sys/devices/system/cpu/cpuidle/cpufreq/scaling_setspeed: No such file or directory >> > [ OK ] >> > /etc/init.d/cpuspeed: line 62: /sys/devices/system/cpu/cpuidle/cpufreq/scaling_governor: No such file or directory >> > Enabling ondemand cpu frequency scaling: [ OK ] >> >> Jarod checked a fix in a day or so ago, might be working its way through >> koji somewhere. > > Yep, it was sitting for a day or two waiting for someone to notice my > bodhi push request. It just got pushed over to stable updates a few > hours ago. Sorry for the noise and thx for your work. /me will look at cvs/koji first next time and not only at the repos Cu thl From jwilson at redhat.com Wed Jul 11 16:48:54 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Wed, 11 Jul 2007 12:48:54 -0400 Subject: cpuspeed und cpuidle In-Reply-To: <469507E1.7040508@redhat.com> References: <20070710164733.GA23467@redhat.com> <469504B2.8090605@leemhuis.info> <20070711163258.GE15688@redhat.com> <469506E1.3000808@redhat.com> <469507E1.7040508@redhat.com> Message-ID: <469509F6.6080101@redhat.com> Chuck Ebbert wrote: > On 07/11/2007 12:35 PM, Jarod Wilson wrote: >>> > Cpuspeed afaics needs an adjustment if cpuidle stays: >>> > >>> > $ LC_ALL=C sudo /etc/init.d/cpuspeed restart >>> > Disabling ondemand cpu frequency scaling: /etc/init.d/cpuspeed: line 212: /sys/devices/system/cpu/cpuidle/cpufreq/scaling_governor: No such file or directory >>> > /etc/init.d/cpuspeed: line 213: /sys/devices/system/cpu/cpuidle/cpufreq/scaling_setspeed: No such file or directory >>> > [ OK ] >>> > /etc/init.d/cpuspeed: line 62: /sys/devices/system/cpu/cpuidle/cpufreq/scaling_governor: No such file or directory >>> > Enabling ondemand cpu frequency scaling: [ OK ] >>> >>> Jarod checked a fix in a day or so ago, might be working its way through >>> koji somewhere. >> Yep, it was sitting for a day or two waiting for someone to notice my >> bodhi push request. It just got pushed over to stable updates a few >> hours ago. > > Fedora 6 too? I submitted a push request for the FC6 update I did w/the other pre-F7 update system, but haven't got any notice about it being pushed just yet. I'll ping someone in rel-eng. Can't wait for FC-6 to die now, so we don't have two different ways of doing things (er, make that three w/the RHEL stuff I do too)... -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From cebbert at redhat.com Wed Jul 11 16:55:49 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Wed, 11 Jul 2007 12:55:49 -0400 Subject: cpuspeed und cpuidle In-Reply-To: <469509F6.6080101@redhat.com> References: <20070710164733.GA23467@redhat.com> <469504B2.8090605@leemhuis.info> <20070711163258.GE15688@redhat.com> <469506E1.3000808@redhat.com> <469507E1.7040508@redhat.com> <469509F6.6080101@redhat.com> Message-ID: <46950B95.80106@redhat.com> On 07/11/2007 12:48 PM, Jarod Wilson wrote: > I submitted a push request for the FC6 update I did w/the other pre-F7 > update system, but haven't got any notice about it being pushed just > yet. I'll ping someone in rel-eng. > > Can't wait for FC-6 to die now, so we don't have two different ways of > doing things (er, make that three w/the RHEL stuff I do too)... > Not until December... I wonder if we shouldn't just be very conservative with FC6 and drop the cpuidle there patch as well. Then that update wouldn't be needed. Otherwise we've got to add another 'requires' to the kernel package. (And I assume the cpuspeed update still works with old 2.6.18 kernels in case someone updates cpuspeed but not the kernel?) From jwilson at redhat.com Wed Jul 11 17:02:46 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Wed, 11 Jul 2007 13:02:46 -0400 Subject: cpuspeed und cpuidle In-Reply-To: <46950B95.80106@redhat.com> References: <20070710164733.GA23467@redhat.com> <469504B2.8090605@leemhuis.info> <20070711163258.GE15688@redhat.com> <469506E1.3000808@redhat.com> <469507E1.7040508@redhat.com> <469509F6.6080101@redhat.com> <46950B95.80106@redhat.com> Message-ID: <46950D36.1050500@redhat.com> Chuck Ebbert wrote: > On 07/11/2007 12:48 PM, Jarod Wilson wrote: >> I submitted a push request for the FC6 update I did w/the other pre-F7 >> update system, but haven't got any notice about it being pushed just >> yet. I'll ping someone in rel-eng. >> >> Can't wait for FC-6 to die now, so we don't have two different ways of >> doing things (er, make that three w/the RHEL stuff I do too)... >> > > Not until December... Yeah, I know. Damned users wanting us to support stuff for more than 6mo... ;) > I wonder if we shouldn't just be very conservative with FC6 and drop > the cpuidle there patch as well. Then that update wouldn't be needed. > Otherwise we've got to add another 'requires' to the kernel package. worksforme, but I don't really run fc6 anywhere anymore either. > (And I assume the cpuspeed update still works with old 2.6.18 kernels > in case someone updates cpuspeed but not the kernel?) Yep, the change is really minor (just a slightly stricter pattern match when looking for per-cpu cpufreq bits in /sys -- match cpu[0-9]* instead of cpu*), works just fine with older kernels. -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From davej at redhat.com Wed Jul 11 17:08:34 2007 From: davej at redhat.com (Dave Jones) Date: Wed, 11 Jul 2007 13:08:34 -0400 Subject: cpuspeed und cpuidle In-Reply-To: <46950B95.80106@redhat.com> References: <20070710164733.GA23467@redhat.com> <469504B2.8090605@leemhuis.info> <20070711163258.GE15688@redhat.com> <469506E1.3000808@redhat.com> <469507E1.7040508@redhat.com> <469509F6.6080101@redhat.com> <46950B95.80106@redhat.com> Message-ID: <20070711170833.GC29507@redhat.com> On Wed, Jul 11, 2007 at 12:55:49PM -0400, Chuck Ebbert wrote: > On 07/11/2007 12:48 PM, Jarod Wilson wrote: > > I submitted a push request for the FC6 update I did w/the other pre-F7 > > update system, but haven't got any notice about it being pushed just > > yet. I'll ping someone in rel-eng. > > > > Can't wait for FC-6 to die now, so we don't have two different ways of > > doing things (er, make that three w/the RHEL stuff I do too)... > > > > Not until December... > > I wonder if we shouldn't just be very conservative with FC6 and drop > the cpuidle there patch as well. Then that update wouldn't be needed. > Otherwise we've got to add another 'requires' to the kernel package. Oh good point, cpuidle is part of that massive -hrt update, so when we drop 64bit tickless it goes away anyway.. > (And I assume the cpuspeed update still works with old 2.6.18 kernels > in case someone updates cpuspeed but not the kernel?) it would, it's just tightening a check for files in sysfs to not pick up the new cpuidle dir, just the cpuN dirs. Dave -- http://www.codemonkey.org.uk From jwilson at redhat.com Wed Jul 11 17:37:23 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Wed, 11 Jul 2007 13:37:23 -0400 Subject: [RFC PATCH] Switch to including config-* instead of kernel-*.config Message-ID: <46951553.2050405@redhat.com> The attached patch switches the kernel rpm over from including the current static kernel-*.config files to instead including the config-* files that are actually in cvs. It means we don't leave kernel-*.config droppings all over the place (following a rebase, its entirely too easy to end up with kernel-2.6.21-*.config and kernel-2.6.22-*.config files laying about, which can sometimes cause odd things to happen), and we don't modify SOURCE files in %prep (see bug 232602), which could otherwise result in repacking an srpm with the same n-v-r with different kernel-*.config files. As a bonus, along the way, this cleans up a number of rpmlint warnings (though there are still a TON to poke at). In the future, this would also make life easier for the RHEL6 and later maintainers, as we typically prefer config changes against the config-* files, rather than against the kernel-*.config files, but (most) non-rh folks don't have cvs access to get at the config-* files right now. Thus far, the only real downside is that it requires moving all the config-* files up to the root of the kernel cvs dir, which is 1) a bit messy and 2) results in losing prior versioning history on those files, since cvs blows. (For the record, I've also done a number of successful builds w/this patch now.) Comments appreciated! -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: dynamic_kernel_config_files.patch Type: text/x-patch Size: 13534 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From cebbert at redhat.com Wed Jul 11 20:46:54 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Wed, 11 Jul 2007 16:46:54 -0400 Subject: [RFC PATCH] Switch to including config-* instead of kernel-*.config In-Reply-To: <46951553.2050405@redhat.com> References: <46951553.2050405@redhat.com> Message-ID: <469541BE.8090609@redhat.com> On 07/11/2007 01:37 PM, Jarod Wilson wrote: > The attached patch switches the kernel rpm over from including the > current static kernel-*.config files to instead including the config-* > files that are actually in cvs. > > It means we don't leave kernel-*.config droppings all over the place > (following a rebase, its entirely too easy to end up with > kernel-2.6.21-*.config and kernel-2.6.22-*.config files laying about, > which can sometimes cause odd things to happen), and we don't modify > SOURCE files in %prep (see bug 232602), which could otherwise result in > repacking an srpm with the same n-v-r with different kernel-*.config > files. As a bonus, along the way, this cleans up a number of rpmlint > warnings (though there are still a TON to poke at). > > In the future, this would also make life easier for the RHEL6 and later > maintainers, as we typically prefer config changes against the config-* > files, rather than against the kernel-*.config files, but (most) non-rh > folks don't have cvs access to get at the config-* files right now. > > Thus far, the only real downside is that it requires moving all the > config-* files up to the root of the kernel cvs dir, which is 1) a bit > messy and 2) results in losing prior versioning history on those files, > since cvs blows. > 1) No big deal, though. 2) There's not much relevant history in there anyway. From jwilson at redhat.com Wed Jul 11 20:49:54 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Wed, 11 Jul 2007 16:49:54 -0400 Subject: [RFC PATCH] Switch to including config-* instead of kernel-*.config In-Reply-To: <469541BE.8090609@redhat.com> References: <46951553.2050405@redhat.com> <469541BE.8090609@redhat.com> Message-ID: <46954272.9040900@redhat.com> Chuck Ebbert wrote: > On 07/11/2007 01:37 PM, Jarod Wilson wrote: >> The attached patch switches the kernel rpm over from including the >> current static kernel-*.config files to instead including the config-* >> files that are actually in cvs. >> >> It means we don't leave kernel-*.config droppings all over the place >> (following a rebase, its entirely too easy to end up with >> kernel-2.6.21-*.config and kernel-2.6.22-*.config files laying about, >> which can sometimes cause odd things to happen), and we don't modify >> SOURCE files in %prep (see bug 232602), which could otherwise result in >> repacking an srpm with the same n-v-r with different kernel-*.config >> files. As a bonus, along the way, this cleans up a number of rpmlint >> warnings (though there are still a TON to poke at). >> >> In the future, this would also make life easier for the RHEL6 and later >> maintainers, as we typically prefer config changes against the config-* >> files, rather than against the kernel-*.config files, but (most) non-rh >> folks don't have cvs access to get at the config-* files right now. >> >> Thus far, the only real downside is that it requires moving all the >> config-* files up to the root of the kernel cvs dir, which is 1) a bit >> messy and 2) results in losing prior versioning history on those files, >> since cvs blows. >> > > 1) No big deal, though. > > 2) There's not much relevant history in there anyway. My thoughts exactly. (Hell, I'd even like to 'mv kernel-2.6.spec kernel.spec', but davej seems to not like that idea so much... ;) -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From ncunning at redhat.com Thu Jul 12 01:56:41 2007 From: ncunning at redhat.com (Nigel Cunningham) Date: Thu, 12 Jul 2007 11:56:41 +1000 Subject: 2.6.22 rebase. In-Reply-To: <20070711162545.GC15688@redhat.com> References: <20070710164733.GA23467@redhat.com> <4694ECF9.3090702@redhat.com> <20070711162545.GC15688@redhat.com> Message-ID: <200707121156.42027.ncunning@redhat.com> Hi. On Thursday 12 July 2007 02:25:45 Dave Jones wrote: > On Wed, Jul 11, 2007 at 10:45:13AM -0400, Chuck Ebbert wrote: > > On 07/11/2007 01:23 AM, Dave Jones wrote: > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=247346 > > > > > > > > Problems start to appear when the hpet stuff for x86_64 went it, and did > > > > not vanish when you disabled the forced-hpet for some of the recent > > > > ICH's from Intel (which afaics [would need the lspci data to be sure] > > > > are in both our machines). > > > > > > > > /me will later update the bug with the lspci output when I'm in front of > > > > my laptop again. > > > > > > Yeah, I'm picking over that bug now. Will try and find a box I can > > > reproduce this on tomorrow. > > > > The Fedora 6 kernel doesn't boot either, at least on a Dell Workstation > > 490, without "nohpet". > > Lets just drop the 64bit tickless stuff for now, it clearly isn't baked, > and isn't going to get much better by the end of the week (which I want > to get something into updates-testing by). > > > AND it requires a version of mkinitrd (6.something) that's not available > > for Fedora 6. (I installed with --nodeps and it seems okay but there's > > no 'symvers' file in /boot/grub for the new kernel.) > > Oops, that part of the specfile update needs fixing. > The require: in F6 went too far forward, and I probably pushed F7 back a rev. Do you (or does anyone else) know if Thomas is aware of these issues? I haven't noticed anything on LKML. Regards, Nigel -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jwboyer at jdub.homelinux.org Thu Jul 12 02:55:30 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 11 Jul 2007 21:55:30 -0500 Subject: [RFC PATCH] Switch to including config-* instead of kernel-*.config In-Reply-To: <46954272.9040900@redhat.com> References: <46951553.2050405@redhat.com> <469541BE.8090609@redhat.com> <46954272.9040900@redhat.com> Message-ID: <1184208930.11325.10.camel@vader.jdub.homelinux.org> On Wed, 2007-07-11 at 16:49 -0400, Jarod Wilson wrote: > Chuck Ebbert wrote: > > On 07/11/2007 01:37 PM, Jarod Wilson wrote: > >> The attached patch switches the kernel rpm over from including the > >> current static kernel-*.config files to instead including the config-* > >> files that are actually in cvs. > >> > >> It means we don't leave kernel-*.config droppings all over the place > >> (following a rebase, its entirely too easy to end up with > >> kernel-2.6.21-*.config and kernel-2.6.22-*.config files laying about, > >> which can sometimes cause odd things to happen), and we don't modify > >> SOURCE files in %prep (see bug 232602), which could otherwise result in > >> repacking an srpm with the same n-v-r with different kernel-*.config > >> files. As a bonus, along the way, this cleans up a number of rpmlint > >> warnings (though there are still a TON to poke at). > >> > >> In the future, this would also make life easier for the RHEL6 and later > >> maintainers, as we typically prefer config changes against the config-* > >> files, rather than against the kernel-*.config files, but (most) non-rh > >> folks don't have cvs access to get at the config-* files right now. > >> > >> Thus far, the only real downside is that it requires moving all the > >> config-* files up to the root of the kernel cvs dir, which is 1) a bit > >> messy and 2) results in losing prior versioning history on those files, > >> since cvs blows. > >> > > > > 1) No big deal, though. > > > > 2) There's not much relevant history in there anyway. > > My thoughts exactly. > > (Hell, I'd even like to 'mv kernel-2.6.spec kernel.spec', but davej > seems to not like that idea so much... ;) Why? josh From davej at redhat.com Thu Jul 12 03:31:36 2007 From: davej at redhat.com (Dave Jones) Date: Wed, 11 Jul 2007 23:31:36 -0400 Subject: 2.6.22 rebase. In-Reply-To: <200707121156.42027.ncunning@redhat.com> References: <20070710164733.GA23467@redhat.com> <4694ECF9.3090702@redhat.com> <20070711162545.GC15688@redhat.com> <200707121156.42027.ncunning@redhat.com> Message-ID: <20070712033136.GF15688@redhat.com> On Thu, Jul 12, 2007 at 11:56:41AM +1000, Nigel Cunningham wrote: > Hi. > > On Thursday 12 July 2007 02:25:45 Dave Jones wrote: > > On Wed, Jul 11, 2007 at 10:45:13AM -0400, Chuck Ebbert wrote: > > > On 07/11/2007 01:23 AM, Dave Jones wrote: > > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=247346 > > > > > > > > > > Problems start to appear when the hpet stuff for x86_64 went it, and > did > > > > > not vanish when you disabled the forced-hpet for some of the recent > > > > > ICH's from Intel (which afaics [would need the lspci data to be > sure] > > > > > are in both our machines). > > > > > > > > > > /me will later update the bug with the lspci output when I'm in > front of > > > > > my laptop again. > > > > > > > > Yeah, I'm picking over that bug now. Will try and find a box I can > > > > reproduce this on tomorrow. > > > > > > The Fedora 6 kernel doesn't boot either, at least on a Dell Workstation > > > 490, without "nohpet". > > > > Lets just drop the 64bit tickless stuff for now, it clearly isn't baked, > > and isn't going to get much better by the end of the week (which I want > > to get something into updates-testing by). > > > > Do you (or does anyone else) know if Thomas is aware of these issues? I > haven't noticed anything on LKML. I've been talking with him. The hpet related stuff is on hold though until Venki gets back from vacation. Dave -- http://www.codemonkey.org.uk From drago01 at gmail.com Thu Jul 12 07:48:20 2007 From: drago01 at gmail.com (dragoran) Date: Thu, 12 Jul 2007 09:48:20 +0200 Subject: 2.6.22 rebase. In-Reply-To: <20070712033136.GF15688@redhat.com> References: <20070710164733.GA23467@redhat.com> <4694ECF9.3090702@redhat.com> <20070711162545.GC15688@redhat.com> <200707121156.42027.ncunning@redhat.com> <20070712033136.GF15688@redhat.com> Message-ID: <4695DCC4.3010408@gmail.com> Dave Jones wrote: > On Thu, Jul 12, 2007 at 11:56:41AM +1000, Nigel Cunningham wrote: > > Hi. > > > > On Thursday 12 July 2007 02:25:45 Dave Jones wrote: > > > On Wed, Jul 11, 2007 at 10:45:13AM -0400, Chuck Ebbert wrote: > > > > On 07/11/2007 01:23 AM, Dave Jones wrote: > > > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=247346 > > > > > > > > > > > > Problems start to appear when the hpet stuff for x86_64 went it, and > > did > > > > > > not vanish when you disabled the forced-hpet for some of the recent > > > > > > ICH's from Intel (which afaics [would need the lspci data to be > > sure] > > > > > > are in both our machines). > > > > > > > > > > > > /me will later update the bug with the lspci output when I'm in > > front of > > > > > > my laptop again. > > > > > > > > > > Yeah, I'm picking over that bug now. Will try and find a box I can > > > > > reproduce this on tomorrow. > > > > > > > > The Fedora 6 kernel doesn't boot either, at least on a Dell Workstation > > > > 490, without "nohpet". > > > > > > Lets just drop the 64bit tickless stuff for now, it clearly isn't baked, > > > and isn't going to get much better by the end of the week (which I want > > > to get something into updates-testing by). > > > > > > > Do you (or does anyone else) know if Thomas is aware of these issues? I > > haven't noticed anything on LKML. > > I've been talking with him. The hpet related stuff is on hold though > until Venki gets back from vacation. > tglx fixed the nohpet bug see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=247346 So can we merge back hrtimers + this patch and give it another try? From drago01 at gmail.com Thu Jul 12 07:49:30 2007 From: drago01 at gmail.com (dragoran) Date: Thu, 12 Jul 2007 09:49:30 +0200 Subject: 2.6.22 rebase. In-Reply-To: <4695DCC4.3010408@gmail.com> References: <20070710164733.GA23467@redhat.com> <4694ECF9.3090702@redhat.com> <20070711162545.GC15688@redhat.com> <200707121156.42027.ncunning@redhat.com> <20070712033136.GF15688@redhat.com> <4695DCC4.3010408@gmail.com> Message-ID: <4695DD0A.3040606@gmail.com> dragoran wrote: > Dave Jones wrote: >> On Thu, Jul 12, 2007 at 11:56:41AM +1000, Nigel Cunningham wrote: >> > Hi. >> > > On Thursday 12 July 2007 02:25:45 Dave Jones wrote: >> > > On Wed, Jul 11, 2007 at 10:45:13AM -0400, Chuck Ebbert wrote: >> > > > On 07/11/2007 01:23 AM, Dave Jones wrote: >> > > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=247346 >> > > > > > > > > > > Problems start to appear when the hpet >> stuff for x86_64 went it, and > did >> > > > > > not vanish when you disabled the forced-hpet for some of >> the recent >> > > > > > ICH's from Intel (which afaics [would need the lspci >> data to be > sure] >> > > > > > are in both our machines). >> > > > > > > > > > > /me will later update the bug with the >> lspci output when I'm in > front of >> > > > > > my laptop again. >> > > > > > > > > Yeah, I'm picking over that bug now. Will try >> and find a box I can >> > > > > reproduce this on tomorrow. >> > > > > > > The Fedora 6 kernel doesn't boot either, at least on >> a Dell Workstation >> > > > 490, without "nohpet". >> > > > > Lets just drop the 64bit tickless stuff for now, it clearly >> isn't baked, >> > > and isn't going to get much better by the end of the week (which >> I want >> > > to get something into updates-testing by). >> > > > > Do you (or does anyone else) know if Thomas is aware of >> these issues? I > haven't noticed anything on LKML. >> >> I've been talking with him. The hpet related stuff is on hold though >> until Venki gets back from vacation. >> > tglx fixed the nohpet bug see > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=247346 > > So can we merge back hrtimers + this patch and give it another try? > and also one more idea: we could also merge back the force hpet patches. maybe there where just affected by this bug (hpet hang). From jwilson at redhat.com Thu Jul 12 13:29:08 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Thu, 12 Jul 2007 09:29:08 -0400 Subject: [RFC PATCH] Switch to including config-* instead of kernel-*.config In-Reply-To: <1184208930.11325.10.camel@vader.jdub.homelinux.org> References: <46951553.2050405@redhat.com> <469541BE.8090609@redhat.com> <46954272.9040900@redhat.com> <1184208930.11325.10.camel@vader.jdub.homelinux.org> Message-ID: <46962CA4.600@redhat.com> Josh Boyer wrote: > On Wed, 2007-07-11 at 16:49 -0400, Jarod Wilson wrote: >> Chuck Ebbert wrote: >>> On 07/11/2007 01:37 PM, Jarod Wilson wrote: >>>> The attached patch switches the kernel rpm over from including the >>>> current static kernel-*.config files to instead including the config-* >>>> files that are actually in cvs. >>>> >>>> It means we don't leave kernel-*.config droppings all over the place >>>> (following a rebase, its entirely too easy to end up with >>>> kernel-2.6.21-*.config and kernel-2.6.22-*.config files laying about, >>>> which can sometimes cause odd things to happen), and we don't modify >>>> SOURCE files in %prep (see bug 232602), which could otherwise result in >>>> repacking an srpm with the same n-v-r with different kernel-*.config >>>> files. As a bonus, along the way, this cleans up a number of rpmlint >>>> warnings (though there are still a TON to poke at). >>>> >>>> In the future, this would also make life easier for the RHEL6 and later >>>> maintainers, as we typically prefer config changes against the config-* >>>> files, rather than against the kernel-*.config files, but (most) non-rh >>>> folks don't have cvs access to get at the config-* files right now. >>>> >>>> Thus far, the only real downside is that it requires moving all the >>>> config-* files up to the root of the kernel cvs dir, which is 1) a bit >>>> messy and 2) results in losing prior versioning history on those files, >>>> since cvs blows. >>>> >>> 1) No big deal, though. >>> >>> 2) There's not much relevant history in there anyway. >> My thoughts exactly. >> >> (Hell, I'd even like to 'mv kernel-2.6.spec kernel.spec', but davej >> seems to not like that idea so much... ;) > > Why? I'm going to assume you're asking "why doesn't davej like that idea", since the mv desire is probably obvious (compliance w/packaging standards). Basically, because cvs sucks, and all revision history goes bye-bye if we do the move. Though really... Dave, how big a deal is that really if we do it this early in rawhide? You can always go to the attic if you *really* need to see some historical info on the spec, and we'll have plenty built back up by the time we get to F8... -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From davej at redhat.com Thu Jul 12 16:26:05 2007 From: davej at redhat.com (Dave Jones) Date: Thu, 12 Jul 2007 12:26:05 -0400 Subject: 2.6.22 rebase. In-Reply-To: <4695DD0A.3040606@gmail.com> References: <20070710164733.GA23467@redhat.com> <4694ECF9.3090702@redhat.com> <20070711162545.GC15688@redhat.com> <200707121156.42027.ncunning@redhat.com> <20070712033136.GF15688@redhat.com> <4695DCC4.3010408@gmail.com> <4695DD0A.3040606@gmail.com> Message-ID: <20070712162605.GD25916@redhat.com> On Thu, Jul 12, 2007 at 09:49:30AM +0200, dragoran wrote: > >> I've been talking with him. The hpet related stuff is on hold though > >> until Venki gets back from vacation. > >> > > tglx fixed the nohpet bug see > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=247346 > > > > So can we merge back hrtimers + this patch and give it another try? > > > and also one more idea: we could also merge back the force hpet patches. > maybe there where just affected by this bug (hpet hang). At this point, I'm going to skip that feature for F6/F7, or we'll never get this update out. Hopefully it'll be in good enough shape to get at least something that'll work for most people into updates-testing by the weekend. I'll add Thomas' stuff back to rawhide once he has patches against latest -git. Dave -- http://www.codemonkey.org.uk From davej at redhat.com Thu Jul 12 16:36:21 2007 From: davej at redhat.com (Dave Jones) Date: Thu, 12 Jul 2007 12:36:21 -0400 Subject: [RFC PATCH] Switch to including config-* instead of kernel-*.config In-Reply-To: <46962CA4.600@redhat.com> References: <46951553.2050405@redhat.com> <469541BE.8090609@redhat.com> <46954272.9040900@redhat.com> <1184208930.11325.10.camel@vader.jdub.homelinux.org> <46962CA4.600@redhat.com> Message-ID: <20070712163621.GE25916@redhat.com> On Thu, Jul 12, 2007 at 09:29:08AM -0400, Jarod Wilson wrote: > I'm going to assume you're asking "why doesn't davej like that idea", > since the mv desire is probably obvious (compliance w/packaging > standards). Basically, because cvs sucks, and all revision history goes > bye-bye if we do the move. Though really... Dave, how big a deal is that > really if we do it this early in rawhide? You can always go to the attic > if you *really* need to see some historical info on the spec, and we'll > have plenty built back up by the time we get to F8... Probably not so big a deal if we do it right now I guess. It's been handy in the past for "it broke somewhere between 1.2345 and 1.2367", but tbh now that we have sensible versioning, that at least partially solves that probably without the need for cvs annotate. Feel free to rename it, but be sure to fix up all the scripts/makefiles too. Dave -- http://www.codemonkey.org.uk From cebbert at redhat.com Thu Jul 12 16:55:03 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Thu, 12 Jul 2007 12:55:03 -0400 Subject: [RFC PATCH] Switch to including config-* instead of kernel-*.config In-Reply-To: <20070712163621.GE25916@redhat.com> References: <46951553.2050405@redhat.com> <469541BE.8090609@redhat.com> <46954272.9040900@redhat.com> <1184208930.11325.10.camel@vader.jdub.homelinux.org> <46962CA4.600@redhat.com> <20070712163621.GE25916@redhat.com> Message-ID: <46965CE7.7030900@redhat.com> On 07/12/2007 12:36 PM, Dave Jones wrote: > On Thu, Jul 12, 2007 at 09:29:08AM -0400, Jarod Wilson wrote: > > I'm going to assume you're asking "why doesn't davej like that idea", > > since the mv desire is probably obvious (compliance w/packaging > > standards). Basically, because cvs sucks, and all revision history goes > > bye-bye if we do the move. Though really... Dave, how big a deal is that > > really if we do it this early in rawhide? You can always go to the attic > > if you *really* need to see some historical info on the spec, and we'll > > have plenty built back up by the time we get to F8... > > Probably not so big a deal if we do it right now I guess. > It's been handy in the past for "it broke somewhere between 1.2345 and > 1.2367", but tbh now that we have sensible versioning, that at least > partially solves that probably without the need for cvs annotate. > > Feel free to rename it, but be sure to fix up all the scripts/makefiles too. Maybe not such a good idea, since lots of external documentation refers to 'kernel-2.6.spec' as well. From davej at redhat.com Thu Jul 12 18:59:46 2007 From: davej at redhat.com (Dave Jones) Date: Thu, 12 Jul 2007 14:59:46 -0400 Subject: [RFC PATCH] Switch to including config-* instead of kernel-*.config In-Reply-To: <46965CE7.7030900@redhat.com> References: <46951553.2050405@redhat.com> <469541BE.8090609@redhat.com> <46954272.9040900@redhat.com> <1184208930.11325.10.camel@vader.jdub.homelinux.org> <46962CA4.600@redhat.com> <20070712163621.GE25916@redhat.com> <46965CE7.7030900@redhat.com> Message-ID: <20070712185946.GB12618@redhat.com> On Thu, Jul 12, 2007 at 12:55:03PM -0400, Chuck Ebbert wrote: > On 07/12/2007 12:36 PM, Dave Jones wrote: > > On Thu, Jul 12, 2007 at 09:29:08AM -0400, Jarod Wilson wrote: > > > I'm going to assume you're asking "why doesn't davej like that idea", > > > since the mv desire is probably obvious (compliance w/packaging > > > standards). Basically, because cvs sucks, and all revision history goes > > > bye-bye if we do the move. Though really... Dave, how big a deal is that > > > really if we do it this early in rawhide? You can always go to the attic > > > if you *really* need to see some historical info on the spec, and we'll > > > have plenty built back up by the time we get to F8... > > > > Probably not so big a deal if we do it right now I guess. > > It's been handy in the past for "it broke somewhere between 1.2345 and > > 1.2367", but tbh now that we have sensible versioning, that at least > > partially solves that probably without the need for cvs annotate. > > > > Feel free to rename it, but be sure to fix up all the scripts/makefiles too. > > Maybe not such a good idea, since lots of external documentation refers > to 'kernel-2.6.spec' as well. Well, it'll catch up eventually. A lot of that documentation needs updating almost every time we do a release anyway for some reason or another. Dave -- http://www.codemonkey.org.uk From jwilson at redhat.com Thu Jul 12 19:22:17 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Thu, 12 Jul 2007 15:22:17 -0400 Subject: [RFC PATCH] Switch to including config-* instead of kernel-*.config In-Reply-To: <46965CE7.7030900@redhat.com> References: <46951553.2050405@redhat.com> <469541BE.8090609@redhat.com> <46954272.9040900@redhat.com> <1184208930.11325.10.camel@vader.jdub.homelinux.org> <46962CA4.600@redhat.com> <20070712163621.GE25916@redhat.com> <46965CE7.7030900@redhat.com> Message-ID: <46967F69.3050405@redhat.com> Chuck Ebbert wrote: > On 07/12/2007 12:36 PM, Dave Jones wrote: >> On Thu, Jul 12, 2007 at 09:29:08AM -0400, Jarod Wilson wrote: >> > I'm going to assume you're asking "why doesn't davej like that idea", >> > since the mv desire is probably obvious (compliance w/packaging >> > standards). Basically, because cvs sucks, and all revision history goes >> > bye-bye if we do the move. Though really... Dave, how big a deal is that >> > really if we do it this early in rawhide? You can always go to the attic >> > if you *really* need to see some historical info on the spec, and we'll >> > have plenty built back up by the time we get to F8... >> >> Probably not so big a deal if we do it right now I guess. >> It's been handy in the past for "it broke somewhere between 1.2345 and >> 1.2367", but tbh now that we have sensible versioning, that at least >> partially solves that probably without the need for cvs annotate. >> >> Feel free to rename it, but be sure to fix up all the scripts/makefiles too. > > Maybe not such a good idea, since lots of external documentation refers > to 'kernel-2.6.spec' as well. With luck, people will be bright enough to figure it out... :) But we can do a possible spec name change separate from the proposed config changes. Speaking of which, they were just checked in (blame davej, he said 'do it'). -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From jwilson at redhat.com Thu Jul 12 19:44:43 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Thu, 12 Jul 2007 15:44:43 -0400 Subject: [RFC PATCH] Switch to including config-* instead of kernel-*.config In-Reply-To: <20070712185946.GB12618@redhat.com> References: <46951553.2050405@redhat.com> <469541BE.8090609@redhat.com> <46954272.9040900@redhat.com> <1184208930.11325.10.camel@vader.jdub.homelinux.org> <46962CA4.600@redhat.com> <20070712163621.GE25916@redhat.com> <46965CE7.7030900@redhat.com> <20070712185946.GB12618@redhat.com> Message-ID: <469684AB.3030007@redhat.com> Dave Jones wrote: > On Thu, Jul 12, 2007 at 12:55:03PM -0400, Chuck Ebbert wrote: > > On 07/12/2007 12:36 PM, Dave Jones wrote: > > > On Thu, Jul 12, 2007 at 09:29:08AM -0400, Jarod Wilson wrote: > > > > I'm going to assume you're asking "why doesn't davej like that idea", > > > > since the mv desire is probably obvious (compliance w/packaging > > > > standards). Basically, because cvs sucks, and all revision history goes > > > > bye-bye if we do the move. Though really... Dave, how big a deal is that > > > > really if we do it this early in rawhide? You can always go to the attic > > > > if you *really* need to see some historical info on the spec, and we'll > > > > have plenty built back up by the time we get to F8... > > > > > > Probably not so big a deal if we do it right now I guess. > > > It's been handy in the past for "it broke somewhere between 1.2345 and > > > 1.2367", but tbh now that we have sensible versioning, that at least > > > partially solves that probably without the need for cvs annotate. > > > > > > Feel free to rename it, but be sure to fix up all the scripts/makefiles too. > > > > Maybe not such a good idea, since lots of external documentation refers > > to 'kernel-2.6.spec' as well. > > Well, it'll catch up eventually. A lot of that documentation needs > updating almost every time we do a release anyway for some reason > or another. And just to be clear, I was only proposing this for rawhide, at least for the time being. -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From roland at redhat.com Wed Jul 18 05:57:21 2007 From: roland at redhat.com (Roland McGrath) Date: Tue, 17 Jul 2007 22:57:21 -0700 (PDT) Subject: f7/rawhide utrace Message-ID: <20070718055721.061B94D05CF@magilla.localdomain> The mondo powerpc update upstream today will take some substantial merging and rejiggery work, and I might do something different tonight instead. If you rebase rawhide before I get there, you will hit trouble. The conflicts outside powerpc are simple. I made a 2.6.22/ backport from the 2.6-current patches (probably same set now in rawhide). That should do fine for f7. Thanks, Roland From cebbert at redhat.com Thu Jul 19 17:52:29 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Thu, 19 Jul 2007 13:52:29 -0400 Subject: Fedora Core 6 Test Update: kernel-2.6.22.1-15.fc6 In-Reply-To: References: Message-ID: <469FA4DD.3000408@redhat.com> On 07/19/2007 01:47 PM, KH KH wrote: > Hello! > > Actually this updated kernel contains the juju firewire... > This will bring some regression, as state here: > https://www.redhat.com/archives/fedora-devel-list/2007-July/msg00843.html > > For example,here is what i wouln't like to see rising for FC-6 also... > http://www.ezplanetone.com/xwiki/bin/view/KnowledgeBase/BrokenFC7FireWire > > Is it possible to prevent thoses regression from appearing into FC-6 ? > If not, this may break many userland applications... Another kernel is building now with the old stack instead of the new one. It also has the libata combined mode option restored. From tonystb at 123mail.cl Fri Jul 20 07:39:07 2007 From: tonystb at 123mail.cl (ANTHONY ELUMELU) Date: Fri, 20 Jul 2007 03:39:07 -0400 (EDT) Subject: PART PAYMENT OF YOUR FUND Message-ID: <20070720073907.864724E1D1C@macnifisense.com> PART PAYMENT OF YOUR FUND FROM THE DESK OF MR. ANTHONY ELUMELU SPECIAL ADVICER TO Federal Ministry of Finance (FMF) Dear Contractor, To Whom It May Concern Your file appeared on my desk two days ago Through Federal Ministry of Finance office that you are among people approved to be paid half of their part payment of USD$8 Million dollars. Signed by the Vice President of Federal Republic of Nigeria, On behalf of Mr. President. I need your information, to reconfirm with the one we have already here in our file to know if you are the Rightful owner to transfer the said sum. Your reply is highly welcome to this office. Thanks and God bless. Regards MR. ANTHONY ELUMELU SPECIAL ADVICER TO FMF From zhihang.wang at gmail.com Sun Jul 22 02:31:24 2007 From: zhihang.wang at gmail.com (zhihang wang) Date: Sun, 22 Jul 2007 10:31:24 +0800 Subject: Why can't I compile redhat 7.2 for INTEL 845G mainboad? Message-ID: <212696550707211931x5d245f85hacce213ade60ba4f@mail.gmail.com> I want to compile linux kernel 2.4.24 for my redhat 7.2. The attached file is my config file and the lspci command result and the error message. The kernel configure file is *configbk*. The mail error message is as following: (**) I810(0): Depth 24, (--) framebuffer bpp 32 (==) I810(0): RGB weight 888 (==) I810(0): Default visual is TrueColor (II) Loading sub module "int10" (II) LoadModule: "int10" (II) Reloading /usr/X11R6/lib/modules/linux/libint10.a (II) I810(0): initializing int10 (EE) I810(0): VBE initialization failed. (II) UnloadModule: "i810" (II) UnloadModule: "int10" (II) UnloadModule: "vgahw" (II) Unloading /usr/X11R6/lib/modules/libvgahw.a (II) UnloadModule: "vbe" (II) Unloading /usr/X11R6/lib/modules/libvbe.a (II) UnloadModule: "int10" (II) Unloading /usr/X11R6/lib/modules/linux/libint10.a (EE) Screen(s) found, but none have a usable configuration. Would you like to give me some idear? -- Best Regards zhihang wang -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pci Type: application/octet-stream Size: 1232 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: XFree86.0.log Type: application/octet-stream Size: 16408 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: XF86Config Type: application/octet-stream Size: 3196 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: configbk Type: application/octet-stream Size: 17086 bytes Desc: not available URL: From davej at redhat.com Sun Jul 22 02:45:51 2007 From: davej at redhat.com (Dave Jones) Date: Sat, 21 Jul 2007 22:45:51 -0400 Subject: Why can't I compile redhat 7.2 for INTEL 845G mainboad? In-Reply-To: <212696550707211931x5d245f85hacce213ade60ba4f@mail.gmail.com> References: <212696550707211931x5d245f85hacce213ade60ba4f@mail.gmail.com> Message-ID: <20070722024551.GA760@redhat.com> On Sun, Jul 22, 2007 at 10:31:24AM +0800, zhihang wang wrote: > I want to compile linux kernel 2.4.24 for my redhat 7.2. The attached file > is my config file and the lspci command result and the error message. > The kernel configure file is *configbk*. > The mail error message is as following: > (**) I810(0): Depth 24, (--) framebuffer bpp 32 > (==) I810(0): RGB weight 888 > (==) I810(0): Default visual is TrueColor > (II) Loading sub module "int10" > (II) LoadModule: "int10" > (II) Reloading /usr/X11R6/lib/modules/linux/libint10.a > (II) I810(0): initializing int10 > (EE) I810(0): VBE initialization failed. > (II) UnloadModule: "i810" > (II) UnloadModule: "int10" > (II) UnloadModule: "vgahw" > (II) Unloading /usr/X11R6/lib/modules/libvgahw.a > (II) UnloadModule: "vbe" > (II) Unloading /usr/X11R6/lib/modules/libvbe.a > (II) UnloadModule: "int10" > (II) Unloading /usr/X11R6/lib/modules/linux/libint10.a > (EE) Screen(s) found, but none have a usable configuration. > > Would you like to give me some idear? Your mail is off-topic for this list. You seem to be having problems with X rather than the kernel. Given the age of the distro you're running, it's not surprising really. The 845 probably never existed when that X package was built, so you lack a driver for it. Dave -- http://www.codemonkey.org.uk From cebbert at redhat.com Wed Jul 25 16:38:34 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Wed, 25 Jul 2007 12:38:34 -0400 Subject: Kernel Prerequisites? Message-ID: <46A77C8A.8090809@redhat.com> See: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=249587 Some users need mdadm to build an initrd. Others might need a new release of cpuspeed (if they use it.) We don't require those packages because not all users will need them, AFAICT -- it depends on what features they use. Should we require all of the packages that might be needed? From katzj at redhat.com Wed Jul 25 17:04:38 2007 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 25 Jul 2007 13:04:38 -0400 Subject: Kernel Prerequisites? In-Reply-To: <46A77C8A.8090809@redhat.com> References: <46A77C8A.8090809@redhat.com> Message-ID: <1185383078.11828.30.camel@localhost.localdomain> On Wed, 2007-07-25 at 12:38 -0400, Chuck Ebbert wrote: > See: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=249587 > > Some users need mdadm to build an initrd. The problem here is that without the requires, it's not guaranteed to be first in the transaction set and thus it can't be used. In the past, we've just added them as requires to mkinitrd, though. mdadm hasn't been there in the past because we used our own raid stuff. Just poked Peter to make the change. And longer term, I'll talk with Panu about other ways of providing hinting for ordering so that we can maybe avoid having to use the Requires crutch > Others might need a new release of cpuspeed (if they use it.) For cpuspeed, it's more a matter of needing to conflict with the old version that won't work with the new kernel. See kernel_dot_org_conflicts and package_conflicts and adjust accordingly. Jeremy From dwmw2 at infradead.org Thu Jul 26 14:57:20 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 26 Jul 2007 15:57:20 +0100 Subject: Plan for tomorrows (20070726) FESCO meeting In-Reply-To: <46A853E7.3030303@hhs.nl> References: <1185384324.2807.4.camel@kennedy> <46A853E7.3030303@hhs.nl> Message-ID: <1185461840.14697.464.camel@pmac.infradead.org> On Thu, 2007-07-26 at 09:57 +0200, Hans de Goede wrote: > Another issue I would like FESco to look at is the current somewhat grey state > of kmod's I'm considering packaging kmod's for uvc (usb video class driver), > lirc and islsm (prism54 softmac driver, which is in F-7, but no longer in > rawhide). But before I invest time in these I would first like to have the > state of kmod's cleared up. I will try to work with there resp. upstreams to > get them in the upstream kernel, and atleast for uvc and islsm upstream merger > is planned already. I would still like to see kmod packages entirely deprecated in Fedora. If you want to maintain that kernel code and ship it with the 'Fedora' brand on it, why don't we just give you commit access to the kernel package? We can trust you to limit yourself to just those areas, and we can trivially disable your patch(es) if it gets in the way of progress. We've done precisely that kind of thing before (including for bcm43xx before that got merged). There's just no need for separate packages. -- dwmw2 From cebbert at redhat.com Thu Jul 26 15:16:22 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Thu, 26 Jul 2007 11:16:22 -0400 Subject: Who decides what drivers go on the install disk? Message-ID: <46A8BAC6.1060200@redhat.com> The arcmsr driver is in-kernel but you can't install to a system using it for the main disk controller: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=249647 Ditto for the uli526x network driver, network installs are impossible on systems using that: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246165 The kernel has the drivers available, but people are reporting these as kernel bugs... From fedora at leemhuis.info Thu Jul 26 15:17:25 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 26 Jul 2007 17:17:25 +0200 Subject: Plan for tomorrows (20070726) FESCO meeting In-Reply-To: <1185461840.14697.464.camel@pmac.infradead.org> References: <1185384324.2807.4.camel@kennedy> <46A853E7.3030303@hhs.nl> <1185461840.14697.464.camel@pmac.infradead.org> Message-ID: <46A8BB05.4080206@leemhuis.info> On 26.07.2007 16:57, David Woodhouse wrote: > On Thu, 2007-07-26 at 09:57 +0200, Hans de Goede wrote: >> Another issue I would like FESco to look at is the current somewhat grey state >> of kmod's I'm considering packaging kmod's for uvc (usb video class driver), >> lirc and islsm (prism54 softmac driver, which is in F-7, but no longer in >> rawhide). But before I invest time in these I would first like to have the >> state of kmod's cleared up. I will try to work with there resp. upstreams to >> get them in the upstream kernel, and atleast for uvc and islsm upstream merger >> is planned already. > > I would still like to see kmod packages entirely deprecated in Fedora. I would like to see kmod packages entirely deprecated in the Everything spin of Fedora 8and thus updates-proper as well), but at the same time would like us to open a official testing area in the scope of the fedora project with a special repo for kmods and its deps to easen testing of that code, help getting it ready for upstream merge and semi-easy access for users. > If you want to maintain that kernel code and ship it with the 'Fedora' > brand on it, why don't we just give you commit access to the kernel > package? We can trust you to limit yourself to just those areas, and we > can trivially disable your patch(es) if it gets in the way of progress. > > We've done precisely that kind of thing before (including for bcm43xx > before that got merged). There's just no need for separate packages. I tend to say that approach is fine for you, Hans and some other developers that are familiar with kernel-coding as those people have shown to be able to get code upstream and know how to work with upstream. But the code in question IMHO should show potential for a nearby upstream merge before it's being added. But users and packagers want some modules that do not head upstream in the near future -- let's take the lirc kernel-modules as example, where the lirc-upstream afaik is not actively working on getting the code into linus kernel. Nobody else is doing that either. I'd prefer to not have stuff like that in fedora's kernel rpm, as that could soon and in a major maintenance nightmare, which we all want to avoid afaics. CU knurd From notting at redhat.com Thu Jul 26 15:18:16 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 26 Jul 2007 11:18:16 -0400 Subject: Who decides what drivers go on the install disk? In-Reply-To: <46A8BAC6.1060200@redhat.com> References: <46A8BAC6.1060200@redhat.com> Message-ID: <20070726151816.GA14308@nostromo.devel.redhat.com> Chuck Ebbert (cebbert at redhat.com) said: > The arcmsr driver is in-kernel but you can't install to a > system using it for the main disk controller: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=249647 > > Ditto for the uli526x network driver, network installs are > impossible on systems using that: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246165 > > The kernel has the drivers available, but people are reporting > these as kernel bugs... module-info in the anaconda package. Bill From dwmw2 at infradead.org Thu Jul 26 15:26:25 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 26 Jul 2007 16:26:25 +0100 Subject: Plan for tomorrows (20070726) FESCO meeting In-Reply-To: <46A8BB05.4080206@leemhuis.info> References: <1185384324.2807.4.camel@kennedy> <46A853E7.3030303@hhs.nl> <1185461840.14697.464.camel@pmac.infradead.org> <46A8BB05.4080206@leemhuis.info> Message-ID: <1185463585.14697.475.camel@pmac.infradead.org> On Thu, 2007-07-26 at 17:17 +0200, Thorsten Leemhuis wrote: > I tend to say that approach is fine for you, Hans and some other > developers that are familiar with kernel-coding as those people have > shown to be able to get code upstream and know how to work with > upstream. Yes, although I'd phrase it as "that approach is fine for anyone who we'd actually want maintaining kernel code with the 'Fedora' name on it". > But the code in question IMHO should show potential for a > nearby upstream merge before it's being added. Absolutely. > But users and packagers want some modules that do not head upstream in > the near future -- let's take the lirc kernel-modules as example, > where the lirc-upstream afaik is not actively working on getting the > code into linus kernel. Nobody else is doing that either. I'd prefer > to not have stuff like that in fedora's kernel rpm, as that could soon > and in a major maintenance nightmare, which we all want to avoid > afaics. It doesn't become any _less_ of a nightmare just because you ship it separately. If we don't want it Fedora's kernel RPM, then we don't want it in Fedora at all. -- dwmw2 From katzj at redhat.com Thu Jul 26 15:29:56 2007 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 26 Jul 2007 11:29:56 -0400 Subject: Who decides what drivers go on the install disk? In-Reply-To: <20070726151816.GA14308@nostromo.devel.redhat.com> References: <46A8BAC6.1060200@redhat.com> <20070726151816.GA14308@nostromo.devel.redhat.com> Message-ID: <1185463796.6960.39.camel@localhost.localdomain> On Thu, 2007-07-26 at 11:18 -0400, Bill Nottingham wrote: > Chuck Ebbert (cebbert at redhat.com) said: > > The arcmsr driver is in-kernel but you can't install to a > > system using it for the main disk controller: > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=249647 > > > > Ditto for the uli526x network driver, network installs are > > impossible on systems using that: > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246165 > > > > The kernel has the drivers available, but people are reporting > > these as kernel bugs... > > module-info in the anaconda package. I should get back to trying to auto-generate this now that we have the modules.scsi, etc files in place... Jeremy From fedora at leemhuis.info Thu Jul 26 15:36:36 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 26 Jul 2007 17:36:36 +0200 Subject: Plan for tomorrows (20070726) FESCO meeting In-Reply-To: <1185463585.14697.475.camel@pmac.infradead.org> References: <1185384324.2807.4.camel@kennedy> <46A853E7.3030303@hhs.nl> <1185461840.14697.464.camel@pmac.infradead.org> <46A8BB05.4080206@leemhuis.info> <1185463585.14697.475.camel@pmac.infradead.org> Message-ID: <46A8BF84.3060509@leemhuis.info> On 26.07.2007 17:26, David Woodhouse wrote: > On Thu, 2007-07-26 at 17:17 +0200, Thorsten Leemhuis wrote: > [...] >> But users and packagers want some modules that do not head upstream in >> the near future -- let's take the lirc kernel-modules as example, >> where the lirc-upstream afaik is not actively working on getting the >> code into linus kernel. Nobody else is doing that either. I'd prefer >> to not have stuff like that in fedora's kernel rpm, as that could soon >> and in a major maintenance nightmare, which we all want to avoid >> afaics. > > It doesn't become any _less_ of a nightmare just because you ship it > separately. I'd even say the nightmare is a bit bigger. > If we don't want it Fedora's kernel RPM, then we don't want > it in Fedora at all. Users want it and we have people wanting to package and maintain those drivers. So let's give them a playing area with a big fat warning sign. That's IMHO way better to leave them out in the cold. Cu knurd From dwmw2 at infradead.org Thu Jul 26 15:40:48 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 26 Jul 2007 16:40:48 +0100 Subject: Plan for tomorrows (20070726) FESCO meeting In-Reply-To: <46A8BF84.3060509@leemhuis.info> References: <1185384324.2807.4.camel@kennedy> <46A853E7.3030303@hhs.nl> <1185461840.14697.464.camel@pmac.infradead.org> <46A8BB05.4080206@leemhuis.info> <1185463585.14697.475.camel@pmac.infradead.org> <46A8BF84.3060509@leemhuis.info> Message-ID: <1185464448.14697.479.camel@pmac.infradead.org> On Thu, 2007-07-26 at 17:36 +0200, Thorsten Leemhuis wrote: > On 26.07.2007 17:26, David Woodhouse wrote: > > On Thu, 2007-07-26 at 17:17 +0200, Thorsten Leemhuis wrote: > > [...] > >> But users and packagers want some modules that do not head upstream in > >> the near future -- let's take the lirc kernel-modules as example, > >> where the lirc-upstream afaik is not actively working on getting the > >> code into linus kernel. Nobody else is doing that either. I'd prefer > >> to not have stuff like that in fedora's kernel rpm, as that could soon > >> and in a major maintenance nightmare, which we all want to avoid > >> afaics. > > > > It doesn't become any _less_ of a nightmare just because you ship it > > separately. > > I'd even say the nightmare is a bit bigger. It's a lot bigger. > > If we don't want it Fedora's kernel RPM, then we don't want > > it in Fedora at all. > > Users want it and we have people wanting to package and maintain those > drivers. So let's give them a playing area with a big fat warning sign. > That's IMHO way better to leave them out in the cold. Users want ponies too. People can go and implement kmod stuff in their own repositories -- we _really_ don't want to be putting the 'Fedora' name on it. If it's good enough for Fedora, it's good enough for the kernel RPM. If not, let them do it elsewhere. -- dwmw2 From j.w.r.degoede at hhs.nl Thu Jul 26 15:48:57 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 26 Jul 2007 17:48:57 +0200 Subject: Plan for tomorrows (20070726) FESCO meeting In-Reply-To: <1185463585.14697.475.camel@pmac.infradead.org> References: <1185384324.2807.4.camel@kennedy> <46A853E7.3030303@hhs.nl> <1185461840.14697.464.camel@pmac.infradead.org> <46A8BB05.4080206@leemhuis.info> <1185463585.14697.475.camel@pmac.infradead.org> Message-ID: <46A8C269.6060904@hhs.nl> David Woodhouse wrote: > On Thu, 2007-07-26 at 17:17 +0200, Thorsten Leemhuis wrote: >> I tend to say that approach is fine for you, Hans and some other >> developers that are familiar with kernel-coding as those people have >> shown to be able to get code upstream and know how to work with >> upstream. > > Yes, although I'd phrase it as "that approach is fine for anyone who > we'd actually want maintaining kernel code with the 'Fedora' name on > it". > >> But the code in question IMHO should show potential for a >> nearby upstream merge before it's being added. > > Absolutely. > >> But users and packagers want some modules that do not head upstream in >> the near future -- let's take the lirc kernel-modules as example, >> where the lirc-upstream afaik is not actively working on getting the >> code into linus kernel. Nobody else is doing that either. I'd prefer >> to not have stuff like that in fedora's kernel rpm, as that could soon >> and in a major maintenance nightmare, which we all want to avoid >> afaics. > > It doesn't become any _less_ of a nightmare just because you ship it > separately. If we don't want it Fedora's kernel RPM, then we don't want > it in Fedora at all. > I must say I like this approach, it avoids the whole problem of having to rebuild kmods all the time and of wether to delay kernel security updates until all kmods are fixetd etc. I do think however that this might cause some pain for Dave Jones, whose job already is hard. Maybe we should ask him what he thinks about this? Regards, Hans From fedora at leemhuis.info Thu Jul 26 16:02:45 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 26 Jul 2007 18:02:45 +0200 Subject: Plan for tomorrows (20070726) FESCO meeting In-Reply-To: <1185464448.14697.479.camel@pmac.infradead.org> References: <1185384324.2807.4.camel@kennedy> <46A853E7.3030303@hhs.nl> <1185461840.14697.464.camel@pmac.infradead.org> <46A8BB05.4080206@leemhuis.info> <1185463585.14697.475.camel@pmac.infradead.org> <46A8BF84.3060509@leemhuis.info> <1185464448.14697.479.camel@pmac.infradead.org> Message-ID: <46A8C5A5.6050303@leemhuis.info> On 26.07.2007 17:40, David Woodhouse wrote: > On Thu, 2007-07-26 at 17:36 +0200, Thorsten Leemhuis wrote: >> On 26.07.2007 17:26, David Woodhouse wrote: >>> On Thu, 2007-07-26 at 17:17 +0200, Thorsten Leemhuis wrote: >>> [...] > People can go and implement kmod stuff in their own repositories -- we > _really_ don't want to be putting the 'Fedora' name on it. > > If it's good enough for Fedora, it's good enough for the kernel RPM. > If not, let them do it elsewhere. I see your point, nevertheless I think we should have kmods (and other experimental stuff) in a special testing repo For me the whole thing is connected to current "target audience" discussion on FAB. Fedora is trying to do lots stuff right, even if it's bad for Fedora (firefox.x86_64 by default, no kmods that don't head upstream, ...). That actually something I why I like Fedora and that's why I agree with you in the "don't put the 'Fedora' name on it". Nevertheless a lot of users and maintainers often fail to understand our high standards. I'd like to give those users a solution and educate them while at it. And I want to get the maintainers involved in that testing ground as they might grow up and soon do other stuff in the project, which will help us growing. CU thl From notting at redhat.com Fri Jul 27 02:13:27 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 26 Jul 2007 22:13:27 -0400 Subject: /lib/modules/$(uname -r)/modules.* [was Re: Who decides what drivers go on the install disk?] In-Reply-To: <1185463796.6960.39.camel@localhost.localdomain> References: <46A8BAC6.1060200@redhat.com> <20070726151816.GA14308@nostromo.devel.redhat.com> <1185463796.6960.39.camel@localhost.localdomain> Message-ID: <20070727021327.GA7175@nostromo.devel.redhat.com> Jeremy Katz (katzj at redhat.com) said: > On Thu, 2007-07-26 at 11:18 -0400, Bill Nottingham wrote: > > Chuck Ebbert (cebbert at redhat.com) said: > > > The arcmsr driver is in-kernel but you can't install to a > > > system using it for the main disk controller: > > > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=249647 > > > > > > Ditto for the uli526x network driver, network installs are > > > impossible on systems using that: > > > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246165 > > > > > > The kernel has the drivers available, but people are reporting > > > these as kernel bugs... > > > > module-info in the anaconda package. > > I should get back to trying to auto-generate this now that we have the > modules.scsi, etc files in place... I have code working for this at the moment... however, it seems wrong. Right now it's based on the modules.scsi, modules.networking, etc. that are shipped in very very recent kernel packages. Looking at how it's done now, we have: # Generate a list of modules for SCSI, sata/pata, and networking. touch $RPM_BUILD_ROOT/lib/modules/$KernelVer/modules.scsi touch $RPM_BUILD_ROOT/lib/modules/$KernelVer/modules.libata touch $RPM_BUILD_ROOT/lib/modules/$KernelVer/modules.networking for i in `cat modnames | grep drivers | grep -v drivers\/ata` do if [ $(nm $i |grep --count scsi_add_host) -ne 0 ]; then basename `echo $i` >> $RPM_BUILD_ROOT/lib/modules/$KernelVer/modules.scsi fi done for i in `cat modnames | grep drivers | grep -v drivers\/scsi` do if [ $(nm $i |grep --count blk_init_queue) -ne 0 ]; then basename `echo $i` >> $RPM_BUILD_ROOT/lib/modules/$KernelVer/modules.scsi fi done for i in `cat modnames | grep drivers\/ata` do if [ $(nm $i |grep --count ata_device_add) -ne 0 -o $(nm $i |grep --count ata_pci_init_one) -ne 0 ]; then basename `echo $i` >> $RPM_BUILD_ROOT/lib/modules/$KernelVer/modules.libata fi done for i in `cat modnames |grep drivers` do if [ $(nm $i |grep --count register_netdev) -ne 0 ]; then basename `echo $i` >> $RPM_BUILD_ROOT/lib/modules/$KernelVer/modules.networking fi done in the kernel spec file. This has the following issues: 1) it's not complete (relatively easily fixed, but leads to...) 2) you can't ever fix the list for kernels that have these lists wrong without rebuilding them. That's bad. 3) anything that uses this will never work on a) older kernels b) 'upstream' kernels, etc. 4) there's a rather arbitrary ata vs. scsi distinction here that seems solely designed to cull the module list for the live CD. Seems strange to me. Frankly, I think this sort of computation should either a) be done in modutils, so that it's upstream for any kernel b) just be done in the places that need this info (anaconda, livecd-tools). They can even just share the implementation. Bill From drago01 at gmail.com Fri Jul 27 11:09:11 2007 From: drago01 at gmail.com (dragoran) Date: Fri, 27 Jul 2007 13:09:11 +0200 Subject: Plan for tomorrows (20070726) FESCO meeting In-Reply-To: <46A8C269.6060904@hhs.nl> References: <1185384324.2807.4.camel@kennedy> <46A853E7.3030303@hhs.nl> <1185461840.14697.464.camel@pmac.infradead.org> <46A8BB05.4080206@leemhuis.info> <1185463585.14697.475.camel@pmac.infradead.org> <46A8C269.6060904@hhs.nl> Message-ID: <46A9D257.7070507@gmail.com> Hans de Goede wrote: > I must say I like this approach, it avoids the whole problem of having > to rebuild kmods all the time and of wether to delay kernel security > updates until all kmods are fixetd etc. I do think however that this > might cause some pain for Dave Jones, whose job already is hard. Maybe > we should ask him what he thinks about this? > well this will cause problems for Dave and Chuck because when one of this modules does not build they either have to fix it or just disable it. 1) creates more work for the kernel maintainers 2) does not solve the problem at all From jcm at redhat.com Fri Jul 27 14:39:04 2007 From: jcm at redhat.com (Jon Masters) Date: Fri, 27 Jul 2007 10:39:04 -0400 Subject: /lib/modules/$(uname -r)/modules.* [was Re: Who decides what drivers go on the install disk?] In-Reply-To: <20070727021327.GA7175@nostromo.devel.redhat.com> References: <46A8BAC6.1060200@redhat.com> <20070726151816.GA14308@nostromo.devel.redhat.com> <1185463796.6960.39.camel@localhost.localdomain> <20070727021327.GA7175@nostromo.devel.redhat.com> Message-ID: <1185547144.23029.28.camel@jcmlaptop> On Thu, 2007-07-26 at 22:13 -0400, Bill Nottingham wrote: > Frankly, I think this sort of computation should either a) be done in modutils, so > that it's upstream for any kernel b) just be done in the places that need this info > (anaconda, livecd-tools). They can even just share the implementation. It can be done in module-init-tools, and probably should be. Let me take a look. Jon. From notting at redhat.com Fri Jul 27 16:28:19 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 27 Jul 2007 12:28:19 -0400 Subject: /lib/modules/$(uname -r)/modules.* [was Re: Who decides what drivers go on the install disk?] In-Reply-To: <1185547144.23029.28.camel@jcmlaptop> References: <46A8BAC6.1060200@redhat.com> <20070726151816.GA14308@nostromo.devel.redhat.com> <1185463796.6960.39.camel@localhost.localdomain> <20070727021327.GA7175@nostromo.devel.redhat.com> <1185547144.23029.28.camel@jcmlaptop> Message-ID: <20070727162819.GA6909@nostromo.devel.redhat.com> Jon Masters (jcm at redhat.com) said: > On Thu, 2007-07-26 at 22:13 -0400, Bill Nottingham wrote: > > > Frankly, I think this sort of computation should either a) be done in modutils, so > > that it's upstream for any kernel b) just be done in the places that need this info > > (anaconda, livecd-tools). They can even just share the implementation. > > It can be done in module-init-tools, and probably should be. Let me take > a look. Actually, the more I think about it... is this really appropriate for all upstream m-i-t users? Especially since it will probably be a never-ending task of adjusting the symbol list to find the proper modules. Bill From jcm at redhat.com Fri Jul 27 16:41:31 2007 From: jcm at redhat.com (Jon Masters) Date: Fri, 27 Jul 2007 12:41:31 -0400 Subject: /lib/modules/$(uname -r)/modules.* [was Re: Who decides what drivers go on the install disk?] In-Reply-To: <20070727162819.GA6909@nostromo.devel.redhat.com> References: <46A8BAC6.1060200@redhat.com> <20070726151816.GA14308@nostromo.devel.redhat.com> <1185463796.6960.39.camel@localhost.localdomain> <20070727021327.GA7175@nostromo.devel.redhat.com> <1185547144.23029.28.camel@jcmlaptop> <20070727162819.GA6909@nostromo.devel.redhat.com> Message-ID: <1185554491.23029.66.camel@jcmlaptop> On Fri, 2007-07-27 at 12:28 -0400, Bill Nottingham wrote: > Jon Masters (jcm at redhat.com) said: > > On Thu, 2007-07-26 at 22:13 -0400, Bill Nottingham wrote: > > > > > Frankly, I think this sort of computation should either a) be done in modutils, so > > > that it's upstream for any kernel b) just be done in the places that need this info > > > (anaconda, livecd-tools). They can even just share the implementation. > > > > It can be done in module-init-tools, and probably should be. Let me take > > a look. > > Actually, the more I think about it... is this really appropriate for all > upstream m-i-t users? Especially since it will probably be a never-ending > task of adjusting the symbol list to find the proper modules. I'm thinking about it ;-) Jon. From katzj at redhat.com Fri Jul 27 17:11:34 2007 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 27 Jul 2007 13:11:34 -0400 Subject: /lib/modules/$(uname -r)/modules.* [was Re: Who decides what drivers go on the install disk?] In-Reply-To: <20070727162819.GA6909@nostromo.devel.redhat.com> References: <46A8BAC6.1060200@redhat.com> <20070726151816.GA14308@nostromo.devel.redhat.com> <1185463796.6960.39.camel@localhost.localdomain> <20070727021327.GA7175@nostromo.devel.redhat.com> <1185547144.23029.28.camel@jcmlaptop> <20070727162819.GA6909@nostromo.devel.redhat.com> Message-ID: <1185556294.15991.38.camel@localhost.localdomain> On Fri, 2007-07-27 at 12:28 -0400, Bill Nottingham wrote: > Jon Masters (jcm at redhat.com) said: > > On Thu, 2007-07-26 at 22:13 -0400, Bill Nottingham wrote: > > > > > Frankly, I think this sort of computation should either a) be done in modutils, so > > > that it's upstream for any kernel b) just be done in the places that need this info > > > (anaconda, livecd-tools). They can even just share the implementation. > > > > It can be done in module-init-tools, and probably should be. Let me take > > a look. > > Actually, the more I think about it... is this really appropriate for all > upstream m-i-t users? Especially since it will probably be a never-ending > task of adjusting the symbol list to find the proper modules. When davej and I talked about it, we decided "probably not". And maintaining two lists of it is insane, so we decided putting the info in the kernel package wasn't a bad thing. Especially as that's where you'll know when you need to change it Jeremy From notting at redhat.com Fri Jul 27 17:43:18 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 27 Jul 2007 13:43:18 -0400 Subject: /lib/modules/$(uname -r)/modules.* [was Re: Who decides what drivers go on the install disk?] In-Reply-To: <1185556294.15991.38.camel@localhost.localdomain> References: <46A8BAC6.1060200@redhat.com> <20070726151816.GA14308@nostromo.devel.redhat.com> <1185463796.6960.39.camel@localhost.localdomain> <20070727021327.GA7175@nostromo.devel.redhat.com> <1185547144.23029.28.camel@jcmlaptop> <20070727162819.GA6909@nostromo.devel.redhat.com> <1185556294.15991.38.camel@localhost.localdomain> Message-ID: <20070727174318.GB7659@nostromo.devel.redhat.com> Jeremy Katz (katzj at redhat.com) said: > > Actually, the more I think about it... is this really appropriate for all > > upstream m-i-t users? Especially since it will probably be a never-ending > > task of adjusting the symbol list to find the proper modules. > > When davej and I talked about it, we decided "probably not". And > maintaining two lists of it is insane, so we decided putting the info in > the kernel package wasn't a bad thing. Especially as that's where > you'll know when you need to change it But that means any time the symbol list changes, you'll need to rebuild the kernel ; you effectively have a DOA kernel for the installer. If it's done at runtime, you can handle whatever kernel you happen to get, even if it's not one of ours. Bill From katzj at redhat.com Fri Jul 27 17:49:51 2007 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 27 Jul 2007 13:49:51 -0400 Subject: /lib/modules/$(uname -r)/modules.* [was Re: Who decides what drivers go on the install disk?] In-Reply-To: <20070727174318.GB7659@nostromo.devel.redhat.com> References: <46A8BAC6.1060200@redhat.com> <20070726151816.GA14308@nostromo.devel.redhat.com> <1185463796.6960.39.camel@localhost.localdomain> <20070727021327.GA7175@nostromo.devel.redhat.com> <1185547144.23029.28.camel@jcmlaptop> <20070727162819.GA6909@nostromo.devel.redhat.com> <1185556294.15991.38.camel@localhost.localdomain> <20070727174318.GB7659@nostromo.devel.redhat.com> Message-ID: <1185558591.15991.44.camel@localhost.localdomain> On Fri, 2007-07-27 at 13:43 -0400, Bill Nottingham wrote: > Jeremy Katz (katzj at redhat.com) said: > > > Actually, the more I think about it... is this really appropriate for all > > > upstream m-i-t users? Especially since it will probably be a never-ending > > > task of adjusting the symbol list to find the proper modules. > > > > When davej and I talked about it, we decided "probably not". And > > maintaining two lists of it is insane, so we decided putting the info in > > the kernel package wasn't a bad thing. Especially as that's where > > you'll know when you need to change it > > But that means any time the symbol list changes, you'll need to rebuild > the kernel ; you effectively have a DOA kernel for the installer. Lots of things can lead to a DOA kernel. It's not like the symbols we're talking about here are things that change frequently. And it's more likely to actually get *done* if it's in the same place that the changes occur. Otherwise, no one's going to tell us that the symbol list changed until someone happens and we're in exactly the same place we are now. There is zero reason why this information should be maintained within the installer,etc > If > it's done at runtime, you can handle whatever kernel you happen to get, > even if it's not one of ours. There are plenty of constraints we have around kernel configuration. Asking for a file to be shipped with the kernel which tells us a little bit about what modules were configured just doesn't seem that out there Jeremy From notting at redhat.com Fri Jul 27 18:03:29 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 27 Jul 2007 14:03:29 -0400 Subject: /lib/modules/$(uname -r)/modules.* [was Re: Who decides what drivers go on the install disk?] In-Reply-To: <1185558591.15991.44.camel@localhost.localdomain> References: <46A8BAC6.1060200@redhat.com> <20070726151816.GA14308@nostromo.devel.redhat.com> <1185463796.6960.39.camel@localhost.localdomain> <20070727021327.GA7175@nostromo.devel.redhat.com> <1185547144.23029.28.camel@jcmlaptop> <20070727162819.GA6909@nostromo.devel.redhat.com> <1185556294.15991.38.camel@localhost.localdomain> <20070727174318.GB7659@nostromo.devel.redhat.com> <1185558591.15991.44.camel@localhost.localdomain> Message-ID: <20070727180329.GB7999@nostromo.devel.redhat.com> Jeremy Katz (katzj at redhat.com) said: > > If > > it's done at runtime, you can handle whatever kernel you happen to get, > > even if it's not one of ours. > > There are plenty of constraints we have around kernel configuration. > Asking for a file to be shipped with the kernel which tells us a little > bit about what modules were configured just doesn't seem that out there In that case, I strongly suggest combining the libata and scsi lists into a single list for block devices - I doubt the 1M savings on the livecd is really worth splitting hairs here. Bill From katzj at redhat.com Fri Jul 27 18:12:28 2007 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 27 Jul 2007 14:12:28 -0400 Subject: /lib/modules/$(uname -r)/modules.* [was Re: Who decides what drivers go on the install disk?] In-Reply-To: <20070727180329.GB7999@nostromo.devel.redhat.com> References: <46A8BAC6.1060200@redhat.com> <20070726151816.GA14308@nostromo.devel.redhat.com> <1185463796.6960.39.camel@localhost.localdomain> <20070727021327.GA7175@nostromo.devel.redhat.com> <1185547144.23029.28.camel@jcmlaptop> <20070727162819.GA6909@nostromo.devel.redhat.com> <1185556294.15991.38.camel@localhost.localdomain> <20070727174318.GB7659@nostromo.devel.redhat.com> <1185558591.15991.44.camel@localhost.localdomain> <20070727180329.GB7999@nostromo.devel.redhat.com> Message-ID: <1185559948.15991.49.camel@localhost.localdomain> On Fri, 2007-07-27 at 14:03 -0400, Bill Nottingham wrote: > Jeremy Katz (katzj at redhat.com) said: > > > If > > > it's done at runtime, you can handle whatever kernel you happen to get, > > > even if it's not one of ours. > > > > There are plenty of constraints we have around kernel configuration. > > Asking for a file to be shipped with the kernel which tells us a little > > bit about what modules were configured just doesn't seem that out there > > In that case, I strongly suggest combining the libata and scsi lists into > a single list for block devices - I doubt the 1M savings on the livecd is > really worth splitting hairs here. Depends on how many copies of the qlogic driver there are ;-) Especially since we'll have to be pulling in firmware, etc eventually. I mean, I guess I can just do manual twiddling to rule out things that aren't under drivers/ata with the livecd. I'm not _that_ tied to having the two separated out if that's the real kicker here Jeremy From notting at redhat.com Fri Jul 27 18:29:11 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 27 Jul 2007 14:29:11 -0400 Subject: /lib/modules/$(uname -r)/modules.* [was Re: Who decides what drivers go on the install disk?] In-Reply-To: <1185559948.15991.49.camel@localhost.localdomain> References: <20070726151816.GA14308@nostromo.devel.redhat.com> <1185463796.6960.39.camel@localhost.localdomain> <20070727021327.GA7175@nostromo.devel.redhat.com> <1185547144.23029.28.camel@jcmlaptop> <20070727162819.GA6909@nostromo.devel.redhat.com> <1185556294.15991.38.camel@localhost.localdomain> <20070727174318.GB7659@nostromo.devel.redhat.com> <1185558591.15991.44.camel@localhost.localdomain> <20070727180329.GB7999@nostromo.devel.redhat.com> <1185559948.15991.49.camel@localhost.localdomain> Message-ID: <20070727182911.GA5691@nostromo.devel.redhat.com> Jeremy Katz (katzj at redhat.com) said: > Depends on how many copies of the qlogic driver there are ;-) RHEL live CDs? What's that? (Actually, I lied - drivers/block + drivers/scsi is 1.3M compressed.) > I mean, I guess I can just do manual twiddling to rule out things that > aren't under drivers/ata with the livecd. I'm not _that_ tied to having > the two separated out if that's the real kicker here OK. I'll tweak the stuff in the spec and send it here for comments. Bill From notting at redhat.com Fri Jul 27 18:29:36 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 27 Jul 2007 14:29:36 -0400 Subject: aic7xxx_old Message-ID: <20070727182936.GB5691@nostromo.devel.redhat.com> Isn't it about time for this to die? Bill From notting at redhat.com Fri Jul 27 21:24:42 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 27 Jul 2007 17:24:42 -0400 Subject: /lib/modules/$(uname -r)/modules.* [was Re: Who decides what drivers go on the install disk?] In-Reply-To: <20070727182911.GA5691@nostromo.devel.redhat.com> References: <1185463796.6960.39.camel@localhost.localdomain> <20070727021327.GA7175@nostromo.devel.redhat.com> <1185547144.23029.28.camel@jcmlaptop> <20070727162819.GA6909@nostromo.devel.redhat.com> <1185556294.15991.38.camel@localhost.localdomain> <20070727174318.GB7659@nostromo.devel.redhat.com> <1185558591.15991.44.camel@localhost.localdomain> <20070727180329.GB7999@nostromo.devel.redhat.com> <1185559948.15991.49.camel@localhost.localdomain> <20070727182911.GA5691@nostromo.devel.redhat.com> Message-ID: <20070727212441.GA6430@nostromo.devel.redhat.com> Bill Nottingham (notting at redhat.com) said: > > I mean, I guess I can just do manual twiddling to rule out things that > > aren't under drivers/ata with the livecd. I'm not _that_ tied to having > > the two separated out if that's the real kicker here > > OK. I'll tweak the stuff in the spec and send it here for comments. Here you go; sorts them into two piles (networking and block), and expands the symbol list to catch some of the missing modules such as ahci and some of the wireless drivers. Bill -------------- next part -------------- Index: kernel.spec =================================================================== RCS file: /cvs/extras/rpms/kernel/devel/kernel.spec,v retrieving revision 1.34 diff -u -r1.34 kernel.spec --- kernel.spec 27 Jul 2007 17:58:01 -0000 1.34 +++ kernel.spec 27 Jul 2007 21:23:41 -0000 @@ -1425,40 +1425,28 @@ cat modnames | xargs chmod u+x # Generate a list of modules for SCSI, sata/pata, and networking. - touch $RPM_BUILD_ROOT/lib/modules/$KernelVer/modules.scsi - touch $RPM_BUILD_ROOT/lib/modules/$KernelVer/modules.libata + touch $RPM_BUILD_ROOT/lib/modules/$KernelVer/modules.block touch $RPM_BUILD_ROOT/lib/modules/$KernelVer/modules.networking - for i in `cat modnames | grep drivers | grep -v drivers\/ata` - do - if [ $(nm $i |grep --count scsi_add_host) -ne 0 ]; - then - basename `echo $i` >> $RPM_BUILD_ROOT/lib/modules/$KernelVer/modules.scsi - fi - done - for i in `cat modnames | grep drivers | grep -v drivers\/scsi` - do - if [ $(nm $i |grep --count blk_init_queue) -ne 0 ]; - then - basename `echo $i` >> $RPM_BUILD_ROOT/lib/modules/$KernelVer/modules.scsi - fi - done - for i in `cat modnames | grep drivers\/ata` - do - if [ $(nm $i |grep --count ata_device_add) -ne 0 -o $(nm $i |grep --count ata_pci_init_one) -ne 0 ]; - then - basename `echo $i` >> $RPM_BUILD_ROOT/lib/modules/$KernelVer/modules.libata - fi - done + drivers=$(grep drivers modnames) - for i in `cat modnames |grep drivers` - do - if [ $(nm $i |grep --count register_netdev) -ne 0 ]; - then - basename `echo $i` >> $RPM_BUILD_ROOT/lib/modules/$KernelVer/modules.networking - fi - done + # networking + netsyms="register_netdev ieee80211_register_hw usbnet_probe" + for i in $drivers ; do + for symbol in $netsyms ; do + nm -u $i | grep -q $symbol && echo ${i##*/} + done + done | sort -u > $RPM_BUILD_ROOT/lib/modules/$KernelVer/modules.networking + + # block + blocksyms="ata_scsi_ioctl scsi_add_host blk_init_queue" + for i in $drivers ; do + for symbol in $blocksyms ; do + nm -u $i | grep -q $symbol && echo ${i##*/} + done + done | sort -u > $RPM_BUILD_ROOT/lib/modules/$KernelVer/modules.block + # detect missing or incorrect license tags for i in `cat modnames` do From samfw at redhat.com Sat Jul 28 20:02:11 2007 From: samfw at redhat.com (Sam Folk-Williams) Date: Sat, 28 Jul 2007 16:02:11 -0400 Subject: typo in new spec file (F7) Message-ID: <46ABA0C3.8000501@redhat.com> Hi, I noticed this in the kernel-2.6.22.1-33.fc7.src.rpm spec file as I was revising the kernel build docs: #% define buildid .local Just need to remove that space before 'define', otherwise we get the following after uncommenting. error: line 15: Unknown tag: % define buildid .local -Sam From ivazqueznet at gmail.com Sat Jul 28 20:23:46 2007 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Sat, 28 Jul 2007 16:23:46 -0400 Subject: typo in new spec file (F7) In-Reply-To: <46ABA0C3.8000501@redhat.com> References: <46ABA0C3.8000501@redhat.com> Message-ID: <1185654226.13492.7.camel@ignacio.lan> On Sat, 2007-07-28 at 16:02 -0400, Sam Folk-Williams wrote: > I noticed this in the kernel-2.6.22.1-33.fc7.src.rpm spec file as I was > revising the kernel build docs: > > #% define buildid .local > > Just need to remove that space before 'define', otherwise we get the > following after uncommenting. > > error: line 15: Unknown tag: % define buildid .local Better yet, double up the percent sign so that rpm doesn't try to interpret the %define macro. -- Ignacio Vazquez-Abrams -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tcallawa at redhat.com Sun Jul 29 05:36:16 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Sun, 29 Jul 2007 00:36:16 -0500 Subject: typo in new spec file (F7) In-Reply-To: <1185654226.13492.7.camel@ignacio.lan> References: <46ABA0C3.8000501@redhat.com> <1185654226.13492.7.camel@ignacio.lan> Message-ID: <1185687376.3765.190.camel@dhcp83-168.boston.redhat.com> On Sat, 2007-07-28 at 16:23 -0400, Ignacio Vazquez-Abrams wrote: > On Sat, 2007-07-28 at 16:02 -0400, Sam Folk-Williams wrote: > > I noticed this in the kernel-2.6.22.1-33.fc7.src.rpm spec file as I was > > revising the kernel build docs: > > > > #% define buildid .local > > > > Just need to remove that space before 'define', otherwise we get the > > following after uncommenting. > > > > error: line 15: Unknown tag: % define buildid .local > > Better yet, double up the percent sign so that rpm doesn't try to > interpret the %define macro. My guess is that the space is there specifically to prevent rpm from interpreting the %define macro (simply # commenting doesn't prevent it). %% is a cleaner way to do it, but some packagers may not realize it disables the macro. ~spot From jwilson at redhat.com Mon Jul 30 00:43:19 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Sun, 29 Jul 2007 20:43:19 -0400 Subject: typo in new spec file (F7) In-Reply-To: <1185687376.3765.190.camel@dhcp83-168.boston.redhat.com> References: <46ABA0C3.8000501@redhat.com> <1185654226.13492.7.camel@ignacio.lan> <1185687376.3765.190.camel@dhcp83-168.boston.redhat.com> Message-ID: <46AD3427.2040209@redhat.com> Tom "spot" Callaway wrote: > On Sat, 2007-07-28 at 16:23 -0400, Ignacio Vazquez-Abrams wrote: >> On Sat, 2007-07-28 at 16:02 -0400, Sam Folk-Williams wrote: >>> I noticed this in the kernel-2.6.22.1-33.fc7.src.rpm spec file as I was >>> revising the kernel build docs: >>> >>> #% define buildid .local >>> >>> Just need to remove that space before 'define', otherwise we get the >>> following after uncommenting. >>> >>> error: line 15: Unknown tag: % define buildid .local >> Better yet, double up the percent sign so that rpm doesn't try to >> interpret the %define macro. > > My guess is that the space is there specifically to prevent rpm from > interpreting the %define macro (simply # commenting doesn't prevent it). Yup. Originally, I think it was a # replacing a %, but at some point, moved to "#% "... Same difference. > %% is a cleaner way to do it, but some packagers may not realize it > disables the macro. While %% may be a bit cleaner, a # in front of it makes more sense to more people I think. -- Jarod Wilson jwilson at redhat.com From ivazqueznet at gmail.com Mon Jul 30 02:17:13 2007 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Sun, 29 Jul 2007 22:17:13 -0400 Subject: typo in new spec file (F7) In-Reply-To: <46AD3427.2040209@redhat.com> References: <46ABA0C3.8000501@redhat.com> <1185654226.13492.7.camel@ignacio.lan> <1185687376.3765.190.camel@dhcp83-168.boston.redhat.com> <46AD3427.2040209@redhat.com> Message-ID: <1185761833.13492.18.camel@ignacio.lan> On Sun, 2007-07-29 at 20:43 -0400, Jarod Wilson wrote: > Tom "spot" Callaway wrote: > > On Sat, 2007-07-28 at 16:23 -0400, Ignacio Vazquez-Abrams wrote: > >> On Sat, 2007-07-28 at 16:02 -0400, Sam Folk-Williams wrote: > >>> I noticed this in the kernel-2.6.22.1-33.fc7.src.rpm spec file as I was > >>> revising the kernel build docs: > >>> > >>> #% define buildid .local > >>> > >>> Just need to remove that space before 'define', otherwise we get the > >>> following after uncommenting. > >>> > >>> error: line 15: Unknown tag: % define buildid .local > >> Better yet, double up the percent sign so that rpm doesn't try to > >> interpret the %define macro. > > > > My guess is that the space is there specifically to prevent rpm from > > interpreting the %define macro (simply # commenting doesn't prevent it). > > Yup. Originally, I think it was a # replacing a %, but at some point, > moved to "#% "... Same difference. > > > %% is a cleaner way to do it, but some packagers may not realize it > > disables the macro. > > While %% may be a bit cleaner, a # in front of it makes more sense to > more people I think. My point is that you need *both* since rpm will interpret the macro regardless of whether or not it's commented out. -- Ignacio Vazquez-Abrams -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jwilson at redhat.com Mon Jul 30 14:21:03 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Mon, 30 Jul 2007 10:21:03 -0400 Subject: typo in new spec file (F7) In-Reply-To: <1185761833.13492.18.camel@ignacio.lan> References: <46ABA0C3.8000501@redhat.com> <1185654226.13492.7.camel@ignacio.lan> <1185687376.3765.190.camel@dhcp83-168.boston.redhat.com> <46AD3427.2040209@redhat.com> <1185761833.13492.18.camel@ignacio.lan> Message-ID: <46ADF3CF.8010008@redhat.com> Ignacio Vazquez-Abrams wrote: > On Sun, 2007-07-29 at 20:43 -0400, Jarod Wilson wrote: >> Tom "spot" Callaway wrote: >>> On Sat, 2007-07-28 at 16:23 -0400, Ignacio Vazquez-Abrams wrote: >>>> On Sat, 2007-07-28 at 16:02 -0400, Sam Folk-Williams wrote: >>>>> I noticed this in the kernel-2.6.22.1-33.fc7.src.rpm spec file as I was >>>>> revising the kernel build docs: >>>>> >>>>> #% define buildid .local >>>>> >>>>> Just need to remove that space before 'define', otherwise we get the >>>>> following after uncommenting. >>>>> >>>>> error: line 15: Unknown tag: % define buildid .local >>>> Better yet, double up the percent sign so that rpm doesn't try to >>>> interpret the %define macro. >>> My guess is that the space is there specifically to prevent rpm from >>> interpreting the %define macro (simply # commenting doesn't prevent it). >> Yup. Originally, I think it was a # replacing a %, but at some point, >> moved to "#% "... Same difference. >> >>> %% is a cleaner way to do it, but some packagers may not realize it >>> disables the macro. >> While %% may be a bit cleaner, a # in front of it makes more sense to >> more people I think. > > My point is that you need *both* since rpm will interpret the macro > regardless of whether or not it's commented out. ...unless of course there's a space after the %, as is currently the case. :) -- Jarod Wilson jwilson at redhat.com