Re: macrofied kernel.spec
Axel Thimm wrote: On Thu, Aug 02, 2007 at 04:34:43PM -0400, Jarod Wilson wrote: Damn, it'd be nice if koji could spread kernel variant builds of the same arch across multiple builders... That's not difficult to do - just have exactly one kernel built in the specfile and pass the flavour on the rpmbuild command line in koji. Same is already happening with the kmdl builds since quite some time: Each one is an independent build entity, just copy the idioms from there. Of course koji needs to support several builds per src.rpm which it already does in a way, and also to pass custom --define arguments to the builds, but that's not difficult to embed in koji and would make koji also the platform of choice for building kmdls (which is not an argument for Fedora-internal consumption, but for wider spread use of koji). With the desire to spin kernel-vanilla rpms off the same source rpm as the current fedora kernels in a way that they aren't scratch builds, I've talked to release engineering about adding support for passing custom flags through the build system before. Unfortunately, they're currently against adding said support, both because of the technical work that would have to be done, and because of some policy matters. If we let builds pass in random flags, the end result binaries might be different than a simple rpmbuild --rebuild would be, we're less sure what was actually built, people could do crazy things, etc., etc., etc. (paraphrasing rel-eng loosely there). Despite that, I'd certainly still like the functionality added, even if its use were restricted to kernels (just what rel-eng wants, more exceptions for the kernel!). Heck, if we could get same-arch kernel variant builds going across multiple build hosts from a single 'make build' invocation, we could maybe even turn on building of a kernel-vanilla package by default without incurring a massive slowdown in 'make build' to 'all builds finished'... -- Jarod Wilson [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: macrofied kernel.spec
Jarod Wilson wrote: Just realized it looks like you also snuck in a kernel-PAE-debug build= variant... ;) Damn, it'd be nice if koji could spread kernel variant builds of the same arch across multiple builders... =20 I didn't add it, it was already there. I just made it uniform with the= others. Maybe the hand-editted duplication had left it not working? O= r not entirely removed when it was intended to be? Huh. So it is... Hrm. Something is apparently causing it to not get built right now though: http://koji.fedoraproject.org/packages/kernel/2.6.23/0.61.rc1.git9.fc8/i6= 86/ (the lack of it showing up there was what made me think you'd added that, serves me right for not looking at the current spec) I'll poke around and see if I can figure out why it isn't getting built. Not obvious at first glance... Oh. I'm an idiot. Of course they aren't building for rawhide. *ALL* kernels are debug kernels in rawhide, so we don't have a separate one. They're building just fine for F7. /me goes back in his hole... -- Jarod Wilson [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: macrofied kernel.spec
On Tue, Jul 31, 2007 at 07:11:05PM -0700, Roland McGrath wrote:
(I say this, but then, I wrote the glibc makefiles as a child, so
my judgment is clearly suspect, and my breeding a lost cause.)
What is this, a counselling list now? :-)
I think this is a nice cleanup on its own. The reason I actually
did it is that the debuginfo package details will have to change
soon when a new find-debuginfo.sh comes in rpm, which is cleaned up
generally and does new magic for the build-id stuff. I really
don't want to have to start dicking with that before it's
consolidated into only one place I have to touch.
I've verified that this is a no-op vs the 0.61 build. i.e., it
generates rpms with the same files and same rpm magic, modulo a few
typo fixes and cosmetic cleanups/consolidation of rpm script fragments.
In the absence of frothing vitriol, I will commit this after
f8-test1 has sailed.
My initial reaction was one of shock, but this could just be
reaction to the sheer size of the diff. I'll take a look at
the post-application specfile later.
One thing I did notice though which seemed non-obvious to me..
+# First the auxiliary packages of the main kernel package.
+%kernel_devel_package
+%kernel_debuginfo_package
+
+
+# Now, each variant package.
+
+%define variant_summary The Linux kernel compiled for SMP machines
+%kernel_variant_package -n SMP smp
Do -debuginfo packages for variants get produced automatically?
I'm assuming yes based on this part of the macro..
+%if %{with_debuginfo}\
+%ifnarch noarch\
+%{expand:%%files %{?2:%{2}-}debuginfo}\
+%defattr(-,root,root)\
+%if %{elf_image_install_path} != \
+%{debuginfodir}/%{elf_image_install_path}/*-%{KVERREL}%{?2}.debug\
+%endif\
+%{debuginfodir}/lib/modules/%{KVERREL}%{?2}\
+%{debuginfodir}/usr/src/kernels/%{KVERREL}%{?2:-%{2}}-%{_target_cpu}\
+%{?-a:%{debuginfodir}%{-a*}.debug}\
+%endif\
+%endif\
+%endif\
but for some reason, it doesn't sit right in my head.
I've no real fundamental objection to this, but don't leave the country
or have any accidents for a while after it goes in :-)
Just as when Jarod did the versioning overhaul, if something goes awry,
you'd probably be able to figure out the problem quicker than those
getting up to speed on what you've done so far.
Dave
--
http://www.codemonkey.org.uk
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: macrofied kernel.spec
Do -debuginfo packages for variants get produced automatically? Yes. The %kernel_variant_package macro uses %kernel_debuginfo_package (and %kernel_devel_package). The main package (kernel) uses those two macros, but not %kernel_variant_package. I didn't define a separate %kernel_debuginfo_files for %kernel_variant_files to use because for %kernel_variant_files the main package is just like the others. I could change it to break them out just to make it clearer. Thanks, Roland ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
macrofied kernel.spec
The patch below revamps kernel.spec using macros to minimize duplication.
There is now very little boilerplate to write/update for each variant
built. It's now just a few %kernel_variant_foo macro lines for each flavor
(plus %description, which is unchanged). When the common boilerplate
details change, there is just one place to go tweak the spec (in a macro
definition) and no way to forget to update all the flavors.
There was an earlier foray into fancy macro use in the kernel spec
file, which got punted because of troubles with ancient rpmbuild
versions. But that was then, and this is now. Since then, the
build systems got fixed to use the proper rpmbuild for each build
version, and anyway are no longer running on RHEL3. No living (or
recently dead) Fedora, nor AFAIK RHEL=4, will have problems with
this spec file.
The diff looks large, but that's because kernel.spec got ~500 lines
shorter. Even with the sprinkling of %%-heavy magic in the macro
definitions, I think the spec file is now overall easier to read.
(I say this, but then, I wrote the glibc makefiles as a child, so
my judgment is clearly suspect, and my breeding a lost cause.)
I think this is a nice cleanup on its own. The reason I actually
did it is that the debuginfo package details will have to change
soon when a new find-debuginfo.sh comes in rpm, which is cleaned up
generally and does new magic for the build-id stuff. I really
don't want to have to start dicking with that before it's
consolidated into only one place I have to touch.
I've verified that this is a no-op vs the 0.61 build. i.e., it
generates rpms with the same files and same rpm magic, modulo a few
typo fixes and cosmetic cleanups/consolidation of rpm script fragments.
In the absence of frothing vitriol, I will commit this after
f8-test1 has sailed.
Thanks,
Roland
--- kernel.spec.~1.44~ 2007-07-31 15:01:40.0 -0700
+++ kernel.spec 2007-07-31 17:44:57.0 -0700
@@ -363,6 +363,11 @@ Summary: The Linux kernel (the core of t
%define _enable_debug_packages 0
%endif
+%define with_pae_debug 0
+%if %with_pae
+%define with_pae_debug %{with_debug}
+%endif
+
#
# Three sets of minimum package version requirements in the form of Conflicts:
# to versions below the minimum
@@ -385,7 +390,12 @@ Summary: The Linux kernel (the core of t
#
# The ld.so.conf.d file we install uses syntax older ldconfig's don't grok.
#
-%define xen_conflicts glibc 2.3.5-1, xen 3.0.1
+%define kernel_xen_conflicts glibc 2.3.5-1, xen 3.0.1
+
+# upto and including kernel 2.4.9 rpms, the 4Gb+ kernel was called
kernel-enterprise
+# now that the smp kernel offers this capability, obsolete the old kernel
+%define kernel_smp_obsoletes kernel-enterprise 2.4.10
+%define kernel_PAE_obsoletes kernel-smp 2.6.17
#
# Packages that need to be installed before the kernel is, because the %post
@@ -393,6 +403,29 @@ Summary: The Linux kernel (the core of t
#
%define kernel_prereq fileutils, module-init-tools, initscripts = 8.11.1-1,
mkinitrd = 6.0.9-7
+#
+# This macro does requires, provides, conflicts, obsoletes for a kernel
package.
+# %%kernel_reqprovconf subpackage
+# It uses any kernel_subpackage_conflicts and kernel_subpackage_obsoletes
+# macros defined above.
+#
+%define kernel_reqprovconf \
+Provides: kernel = %{rpmversion}-%{pkg_release}\
+Provides: kernel-%{_target_cpu} = %{rpmversion}-%{pkg_release}\
+Provides: kernel-drm = 4.3.0\
+Provides: kernel-drm-nouveau = 6\
+Requires(pre): %{kernel_prereq}\
+Conflicts: %{kernel_dot_org_conflicts}\
+Conflicts: %{package_conflicts}\
+%{?1:%{expand:%%{?kernel_%1_conflicts:Conflicts: %%{kernel_%1_conflicts\
+%{?1:%{expand:%%{?kernel_%1_obsoletes:Obsoletes: %%{kernel_%1_obsoletes\
+# We can't let RPM do the dependencies automatic because it'll then pick up\
+# a correct but undesirable perl dependency from the module headers which\
+# isn't required for the kernel proper to function\
+AutoReq: no\
+AutoProv: yes\
+%{nil}
+
Name: kernel%{?variant}
Group: System Environment/Kernel
License: GPLv2
@@ -403,17 +436,11 @@ Release: %{pkg_release}
# SET %nobuildarches (ABOVE) INSTEAD
ExclusiveArch: noarch %{all_x86} x86_64 ppc ppc64 ia64 sparc sparc64 s390x
alpha alphaev56
ExclusiveOS: Linux
-Provides: kernel-drm = 4.3.0
-Provides: kernel-drm-nouveau = 6
-Provides: kernel-%{_target_cpu} = %{rpmversion}-%{release}
-Requires(pre): %{kernel_prereq}
-Conflicts: %{kernel_dot_org_conflicts}
-Conflicts: %{package_conflicts}
-# We can't let RPM do the dependencies automatic because it'll then pick up
-# a correct but undesirable perl dependency from the module headers which
-# isn't required for the kernel proper to function
-AutoReq: no
-AutoProv: yes
+
+%kernel_reqprovconf
+%ifarch x86_64
+Obsoletes: kernel-smp
+%endif
#
@@ -601,24 +628,37 @@ Patch1230: linux-2.6-powerpc-spu-vicinit
BuildRoot: %{_tmppath}/kernel-%{KVERREL}-root-%{_target_cpu}
-%ifarch x86_64
-Obsoletes: kernel-smp
-%endif
-
%description
The
