2:32 p.m.
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
2:38 p.m.
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
2:43 p.m.
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...
2:46 p.m.
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
2:52 p.m.
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
2:52 p.m.
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
2:53 p.m.
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(a)redhat.com
5:36 p.m.
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
5:49 p.m.
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
8:48 p.m.
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(a)redhat.com
1:02 a.m.
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
7:47 a.m.
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(a)redhat.com
7:58 a.m.
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
11:49 a.m.
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
knurd
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
--
Jarod Wilson
jwilson(a)redhat.com
11:54 a.m.
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:
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(a)redhat.com
2:28 p.m.
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(a)redhat.com
4:05 p.m.
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(a)redhat.com
5873
days inactive
5874
days old
kernel@lists.fedoraproject.org
16 comments
6 participants
participants (6)
-
Dave Jones -
Jarod Wilson -
Jeremy Katz -
Kyle McMartin -
Roland McGrath -
Thorsten Leemhuis