I took a stab at bz 197065 and arrived at the patch below.
Would appreciate some eyeballs before I commit from people
familiar with the macro goo in the specfile. (Hi Roland!)
Aparently pm-utils will need a change to cope with the changed
filename, but I think that should be the limit of the damage.
(oprofile will need to append the archname on the end of System.map-$ver
filenames, but they''re user-passed anyway, and not coded anywhere afaik
Hmm. Not sure about Systemtap).
Comments?
Index: kernel.spec
==================================================================RCS file:
/cvs/pkgs/rpms/kernel/devel/kernel.spec,v
retrieving revision 1.521
diff -u -p -r1.521 kernel.spec
--- kernel.spec 21 Mar 2008 15:27:16 -0000 1.521
+++ kernel.spec 24 Mar 2008 19:20:58 -0000
@@ -1268,15 +1268,15 @@ BuildKernel() {
mkdir -p $RPM_BUILD_ROOT%{debuginfodir}/%{image_install_path}
%endif
mkdir -p $RPM_BUILD_ROOT/%{image_install_path}
- install -m 644 .config $RPM_BUILD_ROOT/boot/config-$KernelVer
- install -m 644 System.map $RPM_BUILD_ROOT/boot/System.map-$KernelVer
- touch $RPM_BUILD_ROOT/boot/initrd-$KernelVer.img
+ install -m 644 .config $RPM_BUILD_ROOT/boot/config-$KernelVer.%{_arch}
+ install -m 644 System.map
$RPM_BUILD_ROOT/boot/System.map-$KernelVer.%{_arch}
+ touch $RPM_BUILD_ROOT/boot/initrd-$KernelVer.img.%{_arch}
if [ -f arch/$Arch/boot/zImage.stub ]; then
cp arch/$Arch/boot/zImage.stub
$RPM_BUILD_ROOT/%{image_install_path}/zImage.stub-$KernelVer || :
fi
$CopyKernel $KernelImage \
- $RPM_BUILD_ROOT/%{image_install_path}/$InstallName-$KernelVer
- chmod 755 $RPM_BUILD_ROOT/%{image_install_path}/$InstallName-$KernelVer
+ $RPM_BUILD_ROOT/%{image_install_path}/$InstallName-$KernelVer.%{_arch}
+ chmod 755
$RPM_BUILD_ROOT/%{image_install_path}/$InstallName-$KernelVer.%{_arch}
mkdir -p $RPM_BUILD_ROOT/lib/modules/$KernelVer
make -s ARCH=$Arch INSTALL_MOD_PATH=$RPM_BUILD_ROOT modules_install
KERNELRELEASE=$KernelVer
@@ -1570,7 +1570,7 @@ fi\
#
%define kernel_variant_posttrans(s:r:v:) \
%{expand:%%posttrans %{?-v*}}\
-/sbin/new-kernel-pkg --package kernel%{?-v:-%{-v*}} --rpmposttrans %{?1}
%{KVERREL}%{?-v*} || exit $?\
+/sbin/new-kernel-pkg --package kernel%{?-v:-%{-v*}} --rpmposttrans %{?1}
%{KVERREL}%{?-v*}.%{_arch} || exit $?\
%{nil}
#
@@ -1587,7 +1587,7 @@ if [ `uname -i` == "x86_64" -o `uname -i
[ -f /etc/sysconfig/kernel ]; then\
/bin/sed -i -e
''s/^DEFAULTKERNEL=%{-s*}$/DEFAULTKERNEL=%{-r*}/''
/etc/sysconfig/kernel || exit $?\
fi}\
-/sbin/new-kernel-pkg --package kernel%{?-v:-%{-v*}} --mkinitrd --depmod
--install %{?1} %{KVERREL}%{?-v*} || exit $?\
+/sbin/new-kernel-pkg --package kernel%{?-v:-%{-v*}} --mkinitrd --depmod
--install %{?1} %{KVERREL}%{?-v*}.%{_arch} || exit $?\
#if [ -x /sbin/weak-modules ]\
#then\
# /sbin/weak-modules --add-kernel %{KVERREL}%{?-v*} || exit $?\
@@ -1600,7 +1600,7 @@ fi}\
#
%define kernel_variant_preun() \
%{expand:%%preun %{?1}}\
-/sbin/new-kernel-pkg --rminitrd --rmmoddep --remove %{KVERREL}%{?1} || exit $?\
+/sbin/new-kernel-pkg --rminitrd --rmmoddep --remove %{KVERREL}%{?1}.%{_arch} ||
exit $?\
#if [ -x /sbin/weak-modules ]\
#then\
# /sbin/weak-modules --remove-kernel %{KVERREL}%{?1} || exit $?\
@@ -1668,10 +1668,9 @@ fi
%if %{1}\
%{expand:%%files %{?2}}\
%defattr(-,root,root)\
-/%{image_install_path}/%{?-k:%{-k*}}%{!?-k:vmlinuz}-%{KVERREL}%{?2}\
-/boot/System.map-%{KVERREL}%{?2}\
-#/boot/symvers-%{KVERREL}%{?2}.gz\
-/boot/config-%{KVERREL}%{?2}\
+/%{image_install_path}/%{?-k:%{-k*}}%{!?-k:vmlinuz}-%{KVERREL}%{?2}.%{_arch}\
+/boot/System.map-%{KVERREL}%{?2}.%{_arch}\
+/boot/config-%{KVERREL}%{?2}.%{_arch}\
%{?-a:%{-a*}}\
%dir /lib/modules/%{KVERREL}%{?2}\
/lib/modules/%{KVERREL}%{?2}/kernel\
--
http://www.codemonkey.org.uk
On Mon, 2008-03-24 at 15:32 -0400, Dave Jones wrote:> I took a stab at bz 197065 and arrived at the patch below. > Would appreciate some eyeballs before I commit from people > familiar with the macro goo in the specfile. (Hi Roland!) > > Aparently pm-utils will need a change to cope with the changed > filename, but I think that should be the limit of the damage. > (oprofile will need to append the archname on the end of System.map-$ver > filenames, but they''re user-passed anyway, and not coded anywhere afaik > Hmm. Not sure about Systemtap).I have this sinking suspicion that more things depend on the filenames, although I''m not coming up with what at the moment... Jeremy
On Mon, Mar 24, 2008 at 03:32:37PM -0400, Dave Jones wrote:> I took a stab at bz 197065 and arrived at the patch below. > Would appreciate some eyeballs before I commit from people > familiar with the macro goo in the specfile. (Hi Roland!) >This looks sane, from my quick once over and fairly novice understanding of rpm...
On Mon, Mar 24, 2008 at 03:38:38PM -0400, Jeremy Katz wrote:> On Mon, 2008-03-24 at 15:32 -0400, Dave Jones wrote: > > I took a stab at bz 197065 and arrived at the patch below. > > Would appreciate some eyeballs before I commit from people > > familiar with the macro goo in the specfile. (Hi Roland!) > > > > Aparently pm-utils will need a change to cope with the changed > > filename, but I think that should be the limit of the damage. > > (oprofile will need to append the archname on the end of System.map-$ver > > filenames, but they''re user-passed anyway, and not coded anywhere afaik > > Hmm. Not sure about Systemtap). > > I have this sinking suspicion that more things depend on the filenames, > although I''m not coming up with what at the moment... >We could use systemtap to run for a while with this set and watch to see if anything boinks the wrong file? cheers, Kyle
On Mon, Mar 24, 2008 at 03:46:44PM -0400, Kyle McMartin wrote: > On Mon, Mar 24, 2008 at 03:38:38PM -0400, Jeremy Katz wrote: > > On Mon, 2008-03-24 at 15:32 -0400, Dave Jones wrote: > > > I took a stab at bz 197065 and arrived at the patch below. > > > Would appreciate some eyeballs before I commit from people > > > familiar with the macro goo in the specfile. (Hi Roland!) > > > > > > Aparently pm-utils will need a change to cope with the changed > > > filename, but I think that should be the limit of the damage. > > > (oprofile will need to append the archname on the end of System.map-$ver > > > filenames, but they''re user-passed anyway, and not coded anywhere afaik > > > Hmm. Not sure about Systemtap). > > > > I have this sinking suspicion that more things depend on the filenames, > > although I''m not coming up with what at the moment... > > > > We could use systemtap to run for a while with this set and watch to see > if anything boinks the wrong file? I''m running a tree-wide grep right now, and it''s already picked up anaconda, bootchart, booty & apt. I expect kexec-tools, and yum will probably be in the list too. I''m starting to wonder if this is worth it for such a small use-case. Dave -- http://www.codemonkey.org.uk
On Mon, 2008-03-24 at 15:46 -0400, Kyle McMartin wrote:> On Mon, Mar 24, 2008 at 03:38:38PM -0400, Jeremy Katz wrote: > > On Mon, 2008-03-24 at 15:32 -0400, Dave Jones wrote: > > > I took a stab at bz 197065 and arrived at the patch below. > > > Would appreciate some eyeballs before I commit from people > > > familiar with the macro goo in the specfile. (Hi Roland!) > > > > > > Aparently pm-utils will need a change to cope with the changed > > > filename, but I think that should be the limit of the damage. > > > (oprofile will need to append the archname on the end of System.map-$ver > > > filenames, but they''re user-passed anyway, and not coded anywhere afaik > > > Hmm. Not sure about Systemtap). > > > > I have this sinking suspicion that more things depend on the filenames, > > although I''m not coming up with what at the moment... > > We could use systemtap to run for a while with this set and watch to see > if anything boinks the wrong file?It''s not running system things -- it''s things like anaconda, the anaconda image build scripts, livecd-creator, mkinitrd, ... So systemtap doesn''t help much (well, unless there are more things depending on it!) And those are just what I''ve found in a quick look :-/ Jeremy
On Monday 24 March 2008 03:32:37 pm Dave Jones wrote:> I took a stab at bz 197065 and arrived at the patch below. > Would appreciate some eyeballs before I commit from people > familiar with the macro goo in the specfile. (Hi Roland!) > > Aparently pm-utils will need a change to cope with the changed > filename, but I think that should be the limit of the damage. > (oprofile will need to append the archname on the end of System.map-$ver > filenames, but they''re user-passed anyway, and not coded anywhere afaik > Hmm. Not sure about Systemtap). > > Comments?Yep!> - install -m 644 .config $RPM_BUILD_ROOT/boot/config-$KernelVer > - install -m 644 System.map $RPM_BUILD_ROOT/boot/System.map-$KernelVer > - touch $RPM_BUILD_ROOT/boot/initrd-$KernelVer.img > + install -m 644 .config $RPM_BUILD_ROOT/boot/config-$KernelVer.%{_arch} > + install -m 644 System.map $RPM_BUILD_ROOT/boot/System.map-$KernelVer.%{_arch} > + touch $RPM_BUILD_ROOT/boot/initrd-$KernelVer.img.%{_arch}For the sake of consistency, I''d try to keep $KernelVer and %{_arch} together. The above would give us for example config-2.6.25-1.fc9.x86_64, System.map-2.6.25-1.fc9.x86_64 and initrd-2.6.25-1.fc9.img.x86_64. I''d make the initrd either initrd-2.6.25-1.fc9.x86_64.img or initrd.img-2.6.25-1.fc9.x86_64.> -/sbin/new-kernel-pkg --package kernel%{?-v:-%{-v*}} --rpmposttrans %{?1} %{KVERREL}%{?-v*} || exit$?\> +/sbin/new-kernel-pkg --package kernel%{?-v:-%{-v*}} --rpmposttrans %{?1} %{KVERREL}%{?-v*}.%{_arch} || exit $?\ %{nil} I suspect this will make new-kernel-package very unhappy, since I think its expecting to be fed what essentially amounts to $(uname -r). -- Jarod Wilson jwilson@redhat.com
I will probably continue to find it desireable to make a dozen different
100-200M partitions to use as /boot for installs, so I don''t really
care
about the name noncollision. But it sure would make it a little simpler
to use (hd0,N)/ TAB in GRUB to remind me which partition is which, as
I''m always doing.
I didn''t really review the spec bits thoroughly. But as far as spec
magic and building goes, I think it should be fine if you just get every
%{KVERREL}%{suffix} and make it %{KVERREL}%{suffix}.%{_arch}.
Except I think you mean %{_target_cpu}, not %{_arch}.
I agree with Jarod that keeping .%{_arch} always immediately after
%{KVERREL}%{suffix} is best. For most things, it just becomes part
of the whole "kernel release string" wad.
As has been noted, a lot of things will get unhappy if they cannot
use foo-`uname -r` and /lib/modules/`uname -r` as file names for
the installed bits. I can speak for systemtap/elfutils, which has
no plan other than /lib/modules/`uname -r` for where to locate the
kernel and module binaries (or user manual intervention with a switch).
Even if it were not for the trouble with finding all the hidden
dependencies on that, tools needing to be compatible across
kernel/distro versions, etc., where would those tools get the
%{_arch} value to look for? uname -m? uname -i? I don''t think
either of those gets i586 when that''s the kernel rpm %{_arch} and
the CPU is an i686, for example.
All this suggests to me that the only thing we really can make fly is to
include the differentiator in EXTRAVERSION. It will be noticeable to
users and probably draw a lot of questions and look redundant in many
places that display the arch too. But it would not be any new can of
worms on technical grounds.
For just 32/64 sharing and not e.g. i586/i686 sharing (both kernels of
same version selectable for the same install), it could be made less
repetitious by not using .%{_target_cpu} but instead just %(L=%{_lib#lib};
test -z "$L" || echo ".$L"), i.e. ".64" or
nothing. (And that would be no
suffix on ia64 et al where lib64 is not used, as well as the 32-bit cases.)
Thanks,
Roland
On Mon, Mar 24, 2008 at 03:36:49PM -0700, Roland McGrath wrote:
> I will probably continue to find it desireable to make a dozen different
> 100-200M partitions to use as /boot for installs, so I don''t
really care
> about the name noncollision. But it sure would make it a little simpler
> to use (hd0,N)/ TAB in GRUB to remind me which partition is which, as
> I''m always doing.
>
> I didn''t really review the spec bits thoroughly. But as far as
spec
> magic and building goes, I think it should be fine if you just get every
> %{KVERREL}%{suffix} and make it %{KVERREL}%{suffix}.%{_arch}.
> Except I think you mean %{_target_cpu}, not %{_arch}.
>
> I agree with Jarod that keeping .%{_arch} always immediately after
> %{KVERREL}%{suffix} is best. For most things, it just becomes part
> of the whole "kernel release string" wad.
>
> As has been noted, a lot of things will get unhappy if they cannot
> use foo-`uname -r` and /lib/modules/`uname -r` as file names for
> the installed bits. I can speak for systemtap/elfutils, which has
> no plan other than /lib/modules/`uname -r` for where to locate the
> kernel and module binaries (or user manual intervention with a switch).
>
> Even if it were not for the trouble with finding all the hidden
> dependencies on that, tools needing to be compatible across
> kernel/distro versions, etc., where would those tools get the
> %{_arch} value to look for? uname -m? uname -i? I don''t think
> either of those gets i586 when that''s the kernel rpm %{_arch} and
> the CPU is an i686, for example.
>
> All this suggests to me that the only thing we really can make fly is to
> include the differentiator in EXTRAVERSION. It will be noticeable to
> users and probably draw a lot of questions and look redundant in many
> places that display the arch too. But it would not be any new can of
> worms on technical grounds.
>
> For just 32/64 sharing and not e.g. i586/i686 sharing (both kernels of
> same version selectable for the same install), it could be made less
> repetitious by not using .%{_target_cpu} but instead just %(L=%{_lib#lib};
> test -z "$L" || echo ".$L"), i.e. ".64" or
nothing. (And that would be no
> suffix on ia64 et al where lib64 is not used, as well as the 32-bit
cases.)
As the number of things that look for vmlinuz scrolled up the screen,
I lost more and more interest in pursueing this. The amount of churn
we''d have to do to various packages doesn''t really pay off vs
the number
of people who ask for this. (I think this is literally the 3rd time
I''ve
seen it requested in the 5 years I''ve been maintaining the kernel)
I''m leaning towards ->WONTFIX
Dave
--
http://www.codemonkey.org.uk
On Monday 24 March 2008 06:36:49 pm Roland McGrath wrote: [...]> All this suggests to me that the only thing we really can make fly is to > include the differentiator in EXTRAVERSION. It will be noticeable to > users and probably draw a lot of questions and look redundant in many > places that display the arch too. But it would not be any new can of > worms on technical grounds.That''s basically the conclusion I came to too, and I''ve got a 2-line spec patch (actually also using %{_target_cpu} instead of %{_arch}) that I''m prodding at. Definitely way too many things that''ll go boom if its not there after some discussion on irc (and on this list). -- Jarod Wilson jwilson@redhat.com
On 24.03.2008 20:53, Jarod Wilson wrote:> On Monday 24 March 2008 03:32:37 pm Dave Jones wrote: >> I took a stab at bz 197065 and arrived at the patch below. >> Would appreciate some eyeballs before I commit from people >> familiar with the macro goo in the specfile. (Hi Roland!) >> >> Aparently pm-utils will need a change to cope with the changed >> filename, but I think that should be the limit of the damage. >> (oprofile will need to append the archname on the end of System.map-$ver >> filenames, but they''re user-passed anyway, and not coded anywhere afaik >> Hmm. Not sure about Systemtap). >> Comments? > Yep! >> - install -m 644 .config $RPM_BUILD_ROOT/boot/config-$KernelVer >> - install -m 644 System.map $RPM_BUILD_ROOT/boot/System.map-$KernelVer >> - touch $RPM_BUILD_ROOT/boot/initrd-$KernelVer.img >> + install -m 644 .config $RPM_BUILD_ROOT/boot/config-$KernelVer.%{_arch} >> + install -m 644 System.map $RPM_BUILD_ROOT/boot/System.map-$KernelVer.%{_arch} >> + touch $RPM_BUILD_ROOT/boot/initrd-$KernelVer.img.%{_arch} > For the sake of consistency, [...]For the sake of consistency we IMHO should use the same delimiter between "$(uname -r)" and arch in all places. E.g. either "." (like quoted above) everywhere or a "-", like we already use in the devel packages (e.g. /usr/src/kernels/2.6.25-0.141.rc6.git5.fc9-x86_64). CU knurd
On Tuesday 25 March 2008 02:02:04 am Thorsten Leemhuis wrote:> On 24.03.2008 20:53, Jarod Wilson wrote: > > On Monday 24 March 2008 03:32:37 pm Dave Jones wrote: > >> I took a stab at bz 197065 and arrived at the patch below. > >> Would appreciate some eyeballs before I commit from people > >> familiar with the macro goo in the specfile. (Hi Roland!)[...]> >> - install -m 644 .config $RPM_BUILD_ROOT/boot/config-$KernelVer > >> - install -m 644 System.map > >> $RPM_BUILD_ROOT/boot/System.map-$KernelVer - touch > >> $RPM_BUILD_ROOT/boot/initrd-$KernelVer.img > >> + install -m 644 .config > >> $RPM_BUILD_ROOT/boot/config-$KernelVer.%{_arch} + install -m 644 > >> System.map $RPM_BUILD_ROOT/boot/System.map-$KernelVer.%{_arch} + > >> touch $RPM_BUILD_ROOT/boot/initrd-$KernelVer.img.%{_arch} > > > > For the sake of consistency, [...] > > For the sake of consistency we IMHO should use the same delimiter > between "$(uname -r)" and arch in all places. E.g. either "." (like > quoted above) everywhere or a "-", like we already use in the devel > packages (e.g. /usr/src/kernels/2.6.25-0.141.rc6.git5.fc9-x86_64).One thing I like about using "." over "-" is that you''d get 2.6.25-xzy.fc9.x86_64 for uname -r output, which matches up nicely with what rpm -q outputs, now that we''re defaulting to outputting n-v-r.arch. -- Jarod Wilson jwilson@redhat.com
On 25.03.2008 13:47, Jarod Wilson wrote:> On Tuesday 25 March 2008 02:02:04 am Thorsten Leemhuis wrote: >> On 24.03.2008 20:53, Jarod Wilson wrote: >>> On Monday 24 March 2008 03:32:37 pm Dave Jones wrote: >>>> I took a stab at bz 197065 and arrived at the patch below. >>>> Would appreciate some eyeballs before I commit from people >>>> familiar with the macro goo in the specfile. (Hi Roland!) > [...] >>>> - install -m 644 .config $RPM_BUILD_ROOT/boot/config-$KernelVer >>>> - install -m 644 System.map >>>> $RPM_BUILD_ROOT/boot/System.map-$KernelVer - touch >>>> $RPM_BUILD_ROOT/boot/initrd-$KernelVer.img >>>> + install -m 644 .config >>>> $RPM_BUILD_ROOT/boot/config-$KernelVer.%{_arch} + install -m 644 >>>> System.map $RPM_BUILD_ROOT/boot/System.map-$KernelVer.%{_arch} + >>>> touch $RPM_BUILD_ROOT/boot/initrd-$KernelVer.img.%{_arch} >>> For the sake of consistency, [...] >> For the sake of consistency we IMHO should use the same delimiter >> between "$(uname -r)" and arch in all places. E.g. either "." (like >> quoted above) everywhere or a "-", like we already use in the devel >> packages (e.g. /usr/src/kernels/2.6.25-0.141.rc6.git5.fc9-x86_64). > One thing I like about using "." over "-" is that you''d get > 2.6.25-xzy.fc9.x86_64 for uname -r output, which matches up nicely with what > rpm -q outputs, now that we''re defaulting to outputting n-v-r.arch.Sounds good. Or, IOW: I''m fine with using "." as delimiter, if we use it for the directories found in the devel packages as well. This whole idea of course means that there are some adjustments needed for kmods in livna (or other kernel module packaging schemes). That shouldn''t be to hard; doing it for F9 might be a bit late, but if you guys really want to go that route I''m sure we''ll find a way to deal with it before F9 ships. CU knurd
On Tuesday 25 March 2008 08:58:00 am Thorsten Leemhuis wrote:> On 25.03.2008 13:47, Jarod Wilson wrote: > > On Tuesday 25 March 2008 02:02:04 am Thorsten Leemhuis wrote: > >> On 24.03.2008 20:53, Jarod Wilson wrote: > >>> On Monday 24 March 2008 03:32:37 pm Dave Jones wrote: > >>>> I took a stab at bz 197065 and arrived at the patch below. > >>>> Would appreciate some eyeballs before I commit from people > >>>> familiar with the macro goo in the specfile. (Hi Roland!) > > > > [...] > > > >>>> - install -m 644 .config $RPM_BUILD_ROOT/boot/config-$KernelVer > >>>> - install -m 644 System.map > >>>> $RPM_BUILD_ROOT/boot/System.map-$KernelVer - touch > >>>> $RPM_BUILD_ROOT/boot/initrd-$KernelVer.img > >>>> + install -m 644 .config > >>>> $RPM_BUILD_ROOT/boot/config-$KernelVer.%{_arch} + install -m 644 > >>>> System.map $RPM_BUILD_ROOT/boot/System.map-$KernelVer.%{_arch} + > >>>> touch $RPM_BUILD_ROOT/boot/initrd-$KernelVer.img.%{_arch} > >>> > >>> For the sake of consistency, [...] > >> > >> For the sake of consistency we IMHO should use the same delimiter > >> between "$(uname -r)" and arch in all places. E.g. either "." (like > >> quoted above) everywhere or a "-", like we already use in the devel > >> packages (e.g. /usr/src/kernels/2.6.25-0.141.rc6.git5.fc9-x86_64). > > > > One thing I like about using "." over "-" is that you''d get > > 2.6.25-xzy.fc9.x86_64 for uname -r output, which matches up nicely with > > what rpm -q outputs, now that we''re defaulting to outputting n-v-r.arch. > > Sounds good. Or, IOW: I''m fine with using "." as delimiter, if we use it > for the directories found in the devel packages as well. > > This whole idea of course means that there are some adjustments needed > for kmods in livna (or other kernel module packaging schemes). That > shouldn''t be to hard; doing it for F9 might be a bit late, but if you > guys really want to go that route I''m sure we''ll find a way to deal with > it before F9 ships. > > CU > knurdTest build up and running: [root@xenon x86_64]# ls /boot/*.x86_64* /boot/config-2.6.25-0.152.rc6.git7.fc9.x86_64 /boot/initrd-2.6.25-0.152.rc6.git7.fc9.x86_64.img /boot/System.map-2.6.25-0.152.rc6.git7.fc9.x86_64 /boot/vmlinuz-2.6.25-0.152.rc6.git7.fc9.x86_64 [root@xenon x86_64]# uname -r 2.6.25-0.152.rc6.git7.fc9.x86_64 [root@xenon x86_64]# ls /lib/modules/ 2.6.25-0.152.rc6.git7.fc9.x86_64 [root@xenon x86_64]# ls /usr/src/kernels/ 2.6.25-0.152.rc6.git7.fc9.x86_64 -- Jarod Wilson jwilson@redhat.com
On Tuesday 25 March 2008 12:49:28 pm Jarod Wilson wrote:> On Tuesday 25 March 2008 08:58:00 am Thorsten Leemhuis wrote: > > On 25.03.2008 13:47, Jarod Wilson wrote: > > > On Tuesday 25 March 2008 02:02:04 am Thorsten Leemhuis wrote: > > >> On 24.03.2008 20:53, Jarod Wilson wrote: > > >>> On Monday 24 March 2008 03:32:37 pm Dave Jones wrote: > > >>>> I took a stab at bz 197065 and arrived at the patch below. > > >>>> Would appreciate some eyeballs before I commit from people > > >>>> familiar with the macro goo in the specfile. (Hi Roland!)[...]> Test build up and running: > > [root@xenon x86_64]# ls /boot/*.x86_64* > /boot/config-2.6.25-0.152.rc6.git7.fc9.x86_64 > /boot/initrd-2.6.25-0.152.rc6.git7.fc9.x86_64.img > /boot/System.map-2.6.25-0.152.rc6.git7.fc9.x86_64 > /boot/vmlinuz-2.6.25-0.152.rc6.git7.fc9.x86_64 > > [root@xenon x86_64]# uname -r > 2.6.25-0.152.rc6.git7.fc9.x86_64 > > [root@xenon x86_64]# ls /lib/modules/ > 2.6.25-0.152.rc6.git7.fc9.x86_64 > > [root@xenon x86_64]# ls /usr/src/kernels/ > 2.6.25-0.152.rc6.git7.fc9.x86_64And here''s the patch I came up with for the above: Index: kernel.spec ==================================================================RCS file: /cvs/pkgs/rpms/kernel/devel/kernel.spec,v retrieving revision 1.536 diff -u -p -r1.536 kernel.spec --- kernel.spec 25 Mar 2008 03:19:46 -0000 1.536 +++ kernel.spec 25 Mar 2008 16:52:04 -0000 @@ -135,7 +135,7 @@ Summary: The Linux kernel (the core of t %define xen_target vmlinuz %define xen_image vmlinuz -%define KVERREL %{PACKAGE_VERSION}-%{PACKAGE_RELEASE} +%define KVERREL %{PACKAGE_VERSION}-%{PACKAGE_RELEASE}.%{_target_cpu} %define hdrarch %_target_cpu %if 0%{!?nopatches:1} @@ -1243,11 +1243,11 @@ BuildKernel() { # Pick the right config file for the kernel we''re building if [ -n "$Flavour" ] ; then Config=kernel-%{version}-%{_target_cpu}-$Flavour.config - DevelDir=/usr/src/kernels/%{KVERREL}-$Flavour-%{_target_cpu} - DevelLink=/usr/src/kernels/%{KVERREL}$Flavour-%{_target_cpu} + DevelDir=/usr/src/kernels/%{KVERREL}-$Flavour + DevelLink=/usr/src/kernels/%{KVERREL}$Flavour else Config=kernel-%{version}-%{_target_cpu}.config - DevelDir=/usr/src/kernels/%{KVERREL}-%{_target_cpu} + DevelDir=/usr/src/kernels/%{KVERREL} DevelLink fi @@ -1259,11 +1259,11 @@ BuildKernel() { CopyKernel=cp fi - KernelVer=%{version}-%{release}$Flavour + KernelVer=%{version}-%{release}$Flavour.%{_target_cpu} echo BUILDING A KERNEL FOR $Flavour %{_target_cpu}... # make sure EXTRAVERSION says what we want it to say - perl -p -i -e "s/^EXTRAVERSION.*/EXTRAVERSION = %{?stablerev}-%{release}$Flavour/" Makefile + perl -p -i -e "s/^EXTRAVERSION.*/EXTRAVERSION = %{?stablerev}-%{release}$Flavour. %{_target_cpu}/" Makefile # if pre-rc1 devel kernel, must fix up SUBLEVEL for our versioning scheme %if !0%{?rcrev} @@ -1585,7 +1585,7 @@ then\ fi\ if [ "$HARDLINK" != "no" -a -x /usr/sbin/hardlink ]\ then\ - (cd /usr/src/kernels/%{KVERREL}-%{?1:%{1}-}%{_target_cpu} &&\ + (cd /usr/src/kernels/%{KVERREL}%{?1:-%{1}} &&\ /usr/bin/find . -type f | while read f; do\ hardlink -c /usr/src/kernels/*.fc*-*/$f $f\ done)\ @@ -1719,8 +1719,8 @@ fi %{?-e:%{-e*}}\ %{expand:%%files %{?2:%{2}-}devel}\ %defattr(-,root,root)\ -%verify(not mtime) /usr/src/kernels/%{KVERREL}%{?2:-%{2}}-%{_target_cpu}\ -/usr/src/kernels/%{KVERREL}%{?2}-%{_target_cpu}\ +%verify(not mtime) /usr/src/kernels/%{KVERREL}%{?2:-%{2}}\ +/usr/src/kernels/%{KVERREL}%{?2}\ %if %{with_debuginfo}\ %ifnarch noarch\ %if %{fancy_debuginfo}\ @@ -1734,7 +1734,7 @@ fi %{debuginfodir}/%{elf_image_install_path}/*-%{KVERREL}%{?2}.debug\ %endif\ %{debuginfodir}/lib/modules/%{KVERREL}%{?2}\ -%{debuginfodir}/usr/src/kernels/%{KVERREL}%{?2:-%{2}}-%{_target_cpu}\ +%{debuginfodir}/usr/src/kernels/%{KVERREL}%{?2:-%{2}}\ %endif\ %endif\ %endif\ -- Jarod Wilson jwilson@redhat.com
On Tuesday 25 March 2008 12:54:07 pm Jarod Wilson wrote:> On Tuesday 25 March 2008 12:49:28 pm Jarod Wilson wrote: > > On Tuesday 25 March 2008 08:58:00 am Thorsten Leemhuis wrote: > > > On 25.03.2008 13:47, Jarod Wilson wrote: > > > > On Tuesday 25 March 2008 02:02:04 am Thorsten Leemhuis wrote: > > > >> On 24.03.2008 20:53, Jarod Wilson wrote: > > > >>> On Monday 24 March 2008 03:32:37 pm Dave Jones wrote: > > > >>>> I took a stab at bz 197065 and arrived at the patch below. > > > >>>> Would appreciate some eyeballs before I commit from people > > > >>>> familiar with the macro goo in the specfile. (Hi Roland!) > > [...] > > > Test build up and running: > > > > [root@xenon x86_64]# ls /boot/*.x86_64* > > /boot/config-2.6.25-0.152.rc6.git7.fc9.x86_64 > > /boot/initrd-2.6.25-0.152.rc6.git7.fc9.x86_64.img > > /boot/System.map-2.6.25-0.152.rc6.git7.fc9.x86_64 > > /boot/vmlinuz-2.6.25-0.152.rc6.git7.fc9.x86_64 > > > > [root@xenon x86_64]# uname -r > > 2.6.25-0.152.rc6.git7.fc9.x86_64 > > > > [root@xenon x86_64]# ls /lib/modules/ > > 2.6.25-0.152.rc6.git7.fc9.x86_64 > > > > [root@xenon x86_64]# ls /usr/src/kernels/ > > 2.6.25-0.152.rc6.git7.fc9.x86_64 > > And here''s the patch I came up with for the above:Crap, disregard that version. Things blow up on flavo{,u}red builds, because the flavo{,u}r gets inserted between the f9 and .arch instead of after arch (the ppc64 build blew up on kdump bits). So a teeny bit more spec hackage required, but its still doable. -- Jarod Wilson jwilson@redhat.com
On Tuesday 25 March 2008 03:28:37 pm Jarod Wilson wrote:> On Tuesday 25 March 2008 12:54:07 pm Jarod Wilson wrote: > > On Tuesday 25 March 2008 12:49:28 pm Jarod Wilson wrote: > > > On Tuesday 25 March 2008 08:58:00 am Thorsten Leemhuis wrote: > > > > On 25.03.2008 13:47, Jarod Wilson wrote: > > > > > On Tuesday 25 March 2008 02:02:04 am Thorsten Leemhuis wrote: > > > > >> On 24.03.2008 20:53, Jarod Wilson wrote: > > > > >>> On Monday 24 March 2008 03:32:37 pm Dave Jones wrote: > > > > >>>> I took a stab at bz 197065 and arrived at the patch below. > > > > >>>> Would appreciate some eyeballs before I commit from people > > > > >>>> familiar with the macro goo in the specfile. (Hi Roland!)[...]> Crap, disregard that version. Things blow up on flavo{,u}red builds, > because the flavo{,u}r gets inserted between the f9 and .arch instead of > after arch (the ppc64 build blew up on kdump bits). So a teeny bit more > spec hackage required, but its still doable.Fixed up version committed and building. I think I''ll go on vacation now... :) -- Jarod Wilson jwilson@redhat.com