-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Matt Sealey wrote:

On Wed, Jan 7, 2009 at 3:56 PM, Matt Sealey wrote:

...

Hi,

However I've stumbled across some real weirdness

The other weirdness I found was simply that the spec files by default refer to a kernel-dummy package - what on earth is this? And where do I get/build/fake it? It seems a thing for build service, or perhaps something build-service does not need, but I had to remove the check for it to get my kernel to build in the end..

Any clues onto where/what I should be doing about this?

kernel-dummy is indeed a build service thing. It's how we ensure that all kernel flavors have the same version/release numbers. If you're building your own flavor, you can ignore it. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkllJ60ACgkQLPWxlyuTD7KPqwCdHfPStkSjbo/lM0zPmeaAhCou MsYAn0WD2woXjvnlWaAESKGnj6Y5MLqP =iHl+ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Matt Sealey wrote:

Hi,

We're working on creating a new kernel flavor here so we can maintain a few patches against the standard -default kernel without trashing peoples' installations (i.e. while you can't have -default and -genesi at the same time because of the cleanup in post-install, at least if it stops working or there's a weird bug, you can still go back to -default without forcing packages, and there would be no package conflicts if someone added our repo, and it had a higher version of -default..)

However I've stumbled across some real weirdness in kernel-source.src - which I then gather builds kernel-source.ppc which then can be used somehow to build kernel-genesi.ppc and .src. For instance, every kernel-$flavor.spec seems to be built from the same source somewhere, with identical changelogs and 99% identical code (the difference being the swapping of the flavor in many places, but that's it). So far I have just hacked up a kernel-genesi.spec myself which is building fine now, but I wondered, where do these files get generated and how can I make my kernel build take part in this process to build an automated spec file?

Yes, they are definitely generated from the same source. We have a kernel-binary.spec.in in the repository that is processed by replacing things like @FLAVOR@ with a real value. There's really no way to add a new flavor to that process since it happens as part of the repository being tarred up into the source RPM. One of my goals is to eliminate as much of that processing as possible. Much of the magic is in scripts that are only part of our repository[1], and that's... suboptimal. In the past month or so I've put some effort into making it easier to do what you're looking to do. The first set of patches remove almost all of the @VAR@ processing in favor of using RPM variables. The result is that you'll be able to add a new flavor by simply changing the %build_flavor variable definition in the beginning of the file and adding a kernel configuration file. Ideally, I'd just like to have a kernel-binary.spec where you do - --define "build_flavor $flavor" on the rpmbuild command line but I'm not sure how we'd go about automating the creation of all the different flavors. For now, you'll have to continue what you're doing. Look for the v2.6.28-staging flavor in the KOTD archive, and you should be able to use the spec files from there once I add those changes in.

Modifying config.conf, series.conf, adding patches is something I've been doing for a while so that has never been a problem to make a custom kernel-default, I would just like to move away from it. Is there any special documentation or a cheat sheet for how to make a new kernel flavor? What was the process to create kernel-ps3, for example, a few versions ago, and how does it get maintained with the rest?

It gets generated from kernel-binary.spec.in, just like everything else. [1] It's not that there's anything particularly sensitive in there, just that we only have so many hours in the day and it's generally better spent fixing bugs. :) - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkllLVEACgkQLPWxlyuTD7KY3QCfQGpd3I061lOOmI1wbIxlooNw YpAAn1+WkNcAGGZjtr0XUeOn4gfX2v6O =IwoP -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org

Jeff Mahoney wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Matt Sealey wrote:

Ideally, I'd just like to have a kernel-binary.spec where you do - --define "build_flavor $flavor" on the rpmbuild command line but I'm not sure how we'd go about automating the creation of all the different flavors.

Okay. I always did --eval "%define jobs 8" and suchlike, now I find there's a prettier way to do it with less work, awesome :]

For now, you'll have to continue what you're doing. Look for the v2.6.28-staging flavor in the KOTD archive, and you should be able to use the spec files from there once I add those changes in.

Okay. I see the pre/post/preun/postun scripts have the same @BLAH@ processing in it. Do you think this could be changed too? It's really hard to test it without building a kernel, extracting scripts and trying them out manually after installing that kernel. It's kind of a long-winded process.. it takes 10 minutes to build the source RPM here and then another couple of hours to install it, then build the entire thing from scratch (from /SOURCES/kernel-flavor.spec), including all the manual handholding and cigarette breaks.

[1] It's not that there's anything particularly sensitive in there, just that we only have so many hours in the day and it's generally better spent fixing bugs. :)

Okay. Actually I have a prudent question about scripts.. is it possible to insert a set of scripts into an already-built RPM? Since testing them out is a complete bitch without ++hours of kernel building here? -- Matt -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org

Question 10000 :) Would there be any benefit at all to allowing tar.lzma inside source rpms? The compression benefit is kind of huge for a Linux kernel (it's one-fifth smaller here - 42MB instead of 50MB). For other packages too, while it would take longer (to compress an existing tarball from gz or bz2 to lzma) to WRITE packages, installing the source package would get much faster due to the faster decompression and multicore and what-not.. This kind of stuff is automatic on FreeBSD where the BSD tar (because it's based on libarchive) can work out what to decompress, whereas GNU tar seems a little lame in comparison.. Thanks. -- Matt -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Matt Sealey wrote:

Jeff Mahoney wrote:

...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Matt Sealey wrote:

Ideally, I'd just like to have a kernel-binary.spec where you do - --define "build_flavor $flavor" on the rpmbuild command line but I'm not sure how we'd go about automating the creation of all the different flavors.

Okay. I always did --eval "%define jobs 8" and suchlike, now I find there's a prettier way to do it with less work, awesome :]

...

For now, you'll have to continue what you're doing. Look for the v2.6.28-staging flavor in the KOTD archive, and you should be able to use the spec files from there once I add those changes in.

Okay. I see the pre/post/preun/postun scripts have the same @BLAH@ processing in it. Do you think this could be changed too? It's really hard to test it without building a kernel, extracting scripts and trying them out manually after installing that kernel. It's kind of a long-winded process.. it takes 10 minutes to build the source RPM here and then another couple of hours to install it, then build the entire thing from scratch (from /SOURCES/kernel-flavor.spec), including all the manual handholding and cigarette breaks.

...

[1] It's not that there's anything particularly sensitive in there, just that we only have so many hours in the day and it's generally better spent fixing bugs. :)

Okay. Actually I have a prudent question about scripts.. is it possible to insert a set of scripts into an already-built RPM? Since testing them out is a complete bitch without ++hours of kernel building here?

-- Matt

The @BLAH@ parts of the scripts get generated from the spec file, not from our external scripts. I'm not a fan of it either, but it shouldn't be a problem. I don't believe it's possible to add scripts to an already-built RPM, but then I'm not an RPM guru. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkluO6gACgkQLPWxlyuTD7KImwCcDbOtZ18obcEOEcLyonVlMBEF NO4AoIWcmlG/FgIfRtke9ZZmyQfsWvmx =Nz6o -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Matt Sealey wrote:

Jeff Mahoney wrote:

...

The @BLAH@ parts of the scripts get generated from the spec file, not from our external scripts. I'm not a fan of it either, but it shouldn't be a problem.

Where? :/

I must be not seeing this bit somehow :(

-- Matt

for script in preun postun pre post; do sed -e "s:@KERNELRELEASE@:$KERNELRELEASE:g" \ -e "s:@IMAGE@:$image:g" \ -e "s:@FLAVOR""@:%build_flavor:g" \ -e "s:@SUBPACKAGE@:%name$sub:g" \ -e "s:@BASE_PACKAGE@:$base_package:g" \ -e "s:@RPM_VERSION_RELEASE@:%version-%release:g" \ -e "s:@RPM_TARGET_CPU@:%_target_cpu:g" \ %_sourcedir/$script.sh > %my_builddir/$script$sub.sh done - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkluPg0ACgkQLPWxlyuTD7JI+gCff7JBxXU3slZczFjHFdE7H6dx fgsAn0roNG/cI49mIm6K/IM35eyVraAq =loZy -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org

Jeff Mahoney wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Matt Sealey wrote:

...

Question 10000 :)

You could probably do it, but bz2 is what's currently mandated by our build system.

Even though all built packages on the system are LZMA compress CPIO? :) How odd.. -- Matt -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org

Jeff Mahoney wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Matt Sealey wrote:

...

Jeff Mahoney wrote:

...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Matt Sealey wrote:

...

Question 10000 :)

You could probably do it, but bz2 is what's currently mandated by our build system. Even though all built packages on the system are LZMA compress CPIO? :)

Yep. *shrug*

I just noticed the kernel packages are built with w9.bzdio set forced, so that it's compatible with older distributions. Is this a hint as to why? Maybe it would be nice for us to override this, for instance --define something in rpmbuild or build or lbuild (build_lzma or something). In our case it doesn't make a great deal of sense to provide a bzip2 kernel for older customers of our kernel builds, since we're not going to support anything lower than 11.0 which is when lzma was introduced and standardized.. I'm currently also looking at all these Obseletes: lines in kernel-blah.spec. Really? Seriously? :D Are you really still supporting 5 year old SUSE installs for customers, based on kernels from 2.2.x and k_athlon stuff? -- Matt -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org

Jeff Mahoney wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On my copy, that looks like: %if %build_vanilla # force bzip2 instead of lzma compression to allow install on older dist versions %define _binary_payload w9.bzdio %endif

... so it only applies to the vanilla flavor.

Ah-ha! Sometimes I get highway hypnosis from all the %#%#%#%%#%#%#%%#%#%%# :D

...

I'm currently also looking at all these Obseletes: lines in kernel-blah.spec. Really? Seriously? :D

Are you really still supporting 5 year old SUSE installs for customers, based on kernels from 2.2.x and k_athlon stuff?

Are you looking at the spec files I just sent you? I thought I removed all that crap.

Yeah.. kernel-source is nice and clean but the kernel-default is again full of that crap. Reattached (dragged it right from the old mail :) I assume this is part of that kernel-flavor.spec.in stuff that you're trying to get rid of/clean up somehow? Or just the wrong kernel-default? -- Matt # # spec file for package kernel-default (Version 2.6.29) # # Copyright (c) 2008 SUSE LINUX Products GmbH, Nuernberg, Germany. # This file and all modifications and additions to the pristine # package are under the same license as the package itself. # # Please submit bugfixes or comments via http://bugs.opensuse.org/ # # norootforbuild %define using_buildservice 0%{?opensuse_bs} %define variant %if %using_buildservice # Strip off the build number ("y") from the "x.y" release number %define source_rel %(release=%release; echo ${release%.*}) %else # We don't have build numbers internally %define source_rel %release %endif # Don't use shell commands in build macros, this won't work outside of rpm %define build_flavor default %define build_kdump 0 %define build_xen 0 %define build_vanilla 0 %define build_ps3 0 %define srcversion 2.6.28 %define patchversion 2.6.29-rc1 # This works fine, but the build service won't expand it for security reasons #%define variant %(case %build_flavor in (rt|rt_*) echo -rt ;; (vanilla) echo -vanilla ;; esac) %if %{build_flavor} == "kdump" %define build_kdump 1 %endif %if %{build_flavor} == "xen" %define build_xen 1 %endif %if %{build_flavor} == "vanilla" %define build_vanilla 1 %endif %if %{build_flavor} == "ps3" %define build_ps3 1 %endif %(chmod +x %_sourcedir/{arch-symbols,guards,config-subst,check-for-config-changes,check-supported-list,built-in-where,modversions,symsets.pl}) %define arch_symbols %(%_sourcedir/arch-symbols %_target_cpu) %define symbols %(set -- %name kernel-%build_flavor $(case %build_flavor in (rt|rt_*) echo RT ;; esac) $([ -e %_sourcedir/extra-symbols ] && cat %_sourcedir/extra-symbols) ; echo $*) %define cpu_arch_flavor %(%_sourcedir/guards %symbols %arch_symbols < %_sourcedir/config.conf | grep '/%build_flavor$') # Define some CONFIG variables as rpm macros as well. (rpm cannot handle # defining them all at once.) %define config_vars CONFIG_MODULES %{expand:%(eval "$(test -n "%cpu_arch_flavor" && tar xfj %_sourcedir/config.tar.bz2 --to-stdout config/%cpu_arch_flavor)"; for config in %config_vars; do echo "%%global $config ${!config:-n}"; done)} %ifarch %ix86 x86_64 %define install_vdso 1 %else %define install_vdso 0 %endif %if %build_vanilla || %build_kdump || %CONFIG_MODULES != "y" %define split_packages 0 %else %define split_packages 1 %endif Name: kernel-%build_flavor Summary: Dummy summary Version: 2.6.29 %if %using_buildservice Release: rc1.<RELEASE> BuildRequires: kernel-source %else %define kernel_source_release %(rpm -q kernel-source%variant-%version --qf "%{RELEASE}") Release: %kernel_source_release BuildRequires: kernel-source%variant = %version-%kernel_source_release %endif License: GPL Group: System/Kernel Url: http://www.kernel.org/ AutoReqProv: on BuildRequires: coreutils module-init-tools sparse BuildRequires: fdupes Provides: %{name}_%_target_cpu = %version-%release %if %split_packages Requires: %name-base_%_target_cpu = %version-%release %endif Requires(pre): coreutils awk Requires(post): module-init-tools # This Requires is wrong, because the post/postun scripts have a # test -x update-bootloader, having perl-Bootloader is not a hard requirement. # But, there is no way to tell rpm or yast to schedule the installation # of perl-Bootloader before kernel-binary.rpm if both are in the list of # packages to install/update. Likewise, this is true for mkinitrd. # A specific version of perl-Bootloader is not required, because the post/postun # scripts handle the two API versions of 10.1/SLES10 GA and 10.2/SLES10 SP1 Requires(post): perl-Bootloader Requires(post): mkinitrd #!BuildIgnore: perl-Bootloader mkinitrd %if ! %using_buildservice BuildRequires: kernel-dummy %endif %ifarch ia64 # arch/ia64/scripts/unwcheck.py BuildRequires: python %endif %ifarch s390 s390x BuildRequires: dwarfextract %endif %if %build_xen %ifarch %ix86 Provides: kernel-xenpae = %version Obsoletes: kernel-xenpae <= %version %endif #!BuildIgnore: xen %endif Provides: %name-nongpl Obsoletes: %name-nongpl %if %build_vanilla # force bzip2 instead of lzma compression to allow install on older dist versions %define _binary_payload w9.bzdio %endif # dead network if installed on SLES10, otherwise it will work (mostly) Conflicts: sysfsutils < 2.0 %if ! %build_vanilla Conflicts: apparmor-profiles <= 2.1 Conflicts: apparmor-parser < 2.3 # root-lvm only works with newer udevs Conflicts: udev < 118 Conflicts: lvm2 < 2.02.33 %endif %ifarch %ix86 Conflicts: libc.so.6()(64bit) %endif Provides: kernel = %version-%source_rel %ifarch %ix86 Provides: k_athlon k_debug k_deflt k_deflt_22 k_deflt_24 k_eide k_laptop k_orig k_pentiu k_pos_ibm k_psmp k_smp k_smp_22 k_smp_24 smp kernel-smp Obsoletes: k_athlon k_debug k_deflt k_deflt_22 k_deflt_24 k_eide k_laptop k_orig k_pentiu k_pos_ibm k_psmp k_smp k_smp_22 k_smp_24 smp kernel-smp %else %ifarch ia64 Provides: k_debug k_deflt k_itanium2 k_itanium2-smp k_smp kernel-sn2 Obsoletes: k_debug k_deflt k_itanium2 k_itanium2-smp k_smp kernel-sn2 %else %ifarch ppc Provides: k_chrp k_chrps k_deflt k_pmac k_pmacs k_prep k_preps Obsoletes: k_chrp k_chrps k_deflt k_pmac k_pmacs k_prep k_preps %else %ifarch ppc64 %else %ifarch s390x Provides: kernel-64bit k_deflt Obsoletes: kernel-64bit k_deflt %else %ifarch x86_64 Provides: k_deflt k_numa k_smp smp kernel-smp Obsoletes: k_deflt k_numa k_smp smp kernel-smp %endif %endif %endif %endif %endif %endif Source10: preun.sh Source11: postun.sh Source12: pre.sh Source13: post.sh Source20: series.conf Source21: config.conf Source22: supported.conf Source30: arch-symbols Source31: guards Source32: config-subst Source33: check-for-config-changes Source34: check-supported-list Source40: build-source-timestamp Source41: built-in-where Source44: find-provides Source45: module-renames Source46: modversions Source47: symsets.pl Source100: config.tar.bz2 Source101: kabi.tar.bz2 %define my_builddir %_builddir/%{name}-%{version} BuildRoot: %{_tmppath}/%{name}-%{version}-build ExclusiveArch: %ix86 ia64 ppc ppc64 s390x x86_64 # These files are found in the kernel-source package: NoSource: 100 NoSource: 101 # The following KMPs have been integrated into the kernel package. Obsoletes: iwlwifi-kmp Obsoletes: ipw3945-kmp Obsoletes: adm8211-kmp Obsoletes: rt2x00-kmp Obsoletes: rfswitch-kmp Obsoletes: uvcvideo-kmp Obsoletes: atl2-kmp Obsoletes: wlan-ng-kmp Obsoletes: et131x-kmp Obsoletes: ivtv-kmp Obsoletes: at76_usb-kmp Obsoletes: pcc-acpi-kmp Obsoletes: uvcvideo-kmp Obsoletes: ralink-rt2860-kmp # Build with bash instead of sh as the shell: this turns on bash # extensions like <(...). %define _buildshell /bin/bash # Provide the exported symbols as "ksym(symbol) = hash" %define __find_provides %my_builddir/find-provides %name # Will modules not listed in supported.conf abort the kernel build (0/1)? %define supported_modules_check 0 %define tolerate_unknown_new_config_options 0 # kABI change tolerance (default in maintenance should be 4, 6, 8 or 15, # 31 is the maximum; see scripts/kabi-checks) %define tolerate_kabi_changes 31 %description Dummy description. %prep %setup -q -c -T -a 100 -a 101 supported_conf() { %_sourcedir/guards %symbols $* < %_sourcedir/supported.conf | sort -u } # Generate the list of modules to be marked as supported { supported_conf base for how in external; do comm -2 -3 <(supported_conf base $how) <(supported_conf base) \ | sed -e 's:$: '"$how"':' done } | sed -e 's,.*/,,' -e 's,\.ko$,,' > %my_builddir/Module.supported # Create grep pattern file for the modules to end up in the base package comm -2 -3 <(supported_conf base) <(supported_conf) \ | sed -e 's:.*/::' -e 's:^:\\/:' -e 's:$:\.ko$:' \ > %my_builddir/grep-for-base-modules # Release number without the EXTRAVERSION RELEASE=%source_rel while [ "$RELEASE" != "${RELEASE#[^0-9]*.}" ]; do RELEASE=${RELEASE#[^0-9]*.} done if [ -f %_sourcedir/localversion ] ; then cat %_sourcedir/localversion > %my_builddir/localversion fi KERNELRELEASE="%patchversion-$RELEASE-%build_flavor" SRCDIR="/usr/src/linux-%patchversion-$RELEASE%variant" BUILDDIR="%buildroot$SRCDIR-obj/%cpu_arch_flavor" mkdir -p "$BUILDDIR" cat config/%cpu_arch_flavor \ | %_sourcedir/config-subst CONFIG_LOCALVERSION '"'-$RELEASE-%build_flavor'"' \ | %_sourcedir/config-subst CONFIG_SUSE_KERNEL y \ %if 0%{?__debug_package:1} | %_sourcedir/config-subst CONFIG_DEBUG_INFO y \ %endif > %my_builddir/.config cpu_arch_flavor="%cpu_arch_flavor" cat >> .rpm-defs <> .rpm-defs <> .rpm-defs sed 's:^sourcedir=.*:sourcedir="%_sourcedir":; s:^builddir=.*:builddir="%my_builddir":' \ %_sourcedir/find-provides >%my_builddir/find-provides chmod +x %my_builddir/find-provides %build source .rpm-defs mkdir -p $BUILDDIR cd $BUILDDIR cp %my_builddir/.config %my_builddir/Module.supported . MAKE_ARGS="$MAKE_ARGS -C $SRCDIR O=$PWD" %if %{tolerate_unknown_new_config_options} MAKE_ARGS="$MAKE_ARGS -k " yes '' | make oldconfig $MAKE_ARGS %else make silentoldconfig $MAKE_ARGS < /dev/null %_sourcedir/check-for-config-changes %my_builddir/.config .config rm -f %my_builddir/.config %endif make prepare $MAKE_ARGS krel=$(make -s kernelrelease $MAKE_ARGS) if [ "$krel" != "$KERNELRELEASE" ]; then echo "Kernel release mismatch: $krel != $KERNELRELEASE" >&2 exit 1 fi cat > .kernel-binary.spec.buildenv </dev/null)" ] ; then dwarfextract vmlinux %buildroot/boot/Kerntypes-$KERNELRELEASE fi %if ! %build_vanilla mkdir -p %buildroot/usr/share/man/man9 [ -d man ] && find man -name '*.9' -exec install -m 644 -D '{}' %buildroot/usr/share/man/man9/ ';' %endif %endif if [ -e init/kerntypes.o ]; then cp init/kerntypes.o %buildroot/boot/Kerntypes-$KERNELRELEASE fi # end of build_kdump %endif for sub in '-base' '' '-extra'; do %if %split_packages if [ "x$sub" = "x-base" ]; then base_package=1 else base_package=0 fi %else base_package=1 %endif for script in preun postun pre post; do sed -e "s:@KERNELRELEASE@:$KERNELRELEASE:g" \ -e "s:@IMAGE@:$image:g" \ -e "s:@FLAVOR""@:%build_flavor:g" \ -e "s:@SUBPACKAGE@:%name$sub:g" \ -e "s:@BASE_PACKAGE@:$base_package:g" \ -e "s:@RPM_VERSION_RELEASE@:%version-%release:g" \ -e "s:@RPM_TARGET_CPU@:%_target_cpu:g" \ %_sourcedir/$script.sh > %my_builddir/$script$sub.sh done done %if %build_kdump || %build_xen || %build_vanilla || %build_ps3 # keep this -suffix list in sync with post.sh and postun.sh suffix=-%build_flavor %endif ln -s $image$suffix %buildroot/boot/$image$suffix ln -s initrd$suffix %buildroot/boot/initrd$suffix cp .config %buildroot/boot/config-$KERNELRELEASE %if %install_vdso # Install the unstripped vdso's that are linked in the kernel image make vdso_install $MAKE_ARGS INSTALL_MOD_PATH=%buildroot %endif # Create a dummy initrd with roughly the size the real one will have. # That way, YaST will know that this package requires some additional # space in /boot. dd if=/dev/zero of=%buildroot/boot/initrd-$KERNELRELEASE \ bs=1024 seek=2047 count=1 if [ $CONFIG_MODULES = y ]; then # Figure out where the symbols that vmlinux exports are defined. # (We need this information below as well as in find-provides; we "annotate" # the original Module.symvers here to make sure that we are consistent in # both places.) %_sourcedir/built-in-where < Module.symvers > Module.symvers.split mv Module.symvers.split Module.symvers gzip -c9 < Module.symvers > %buildroot/boot/symvers-$KERNELRELEASE.gz make modules_install $MAKE_ARGS INSTALL_MOD_PATH=%buildroot if ! %_sourcedir/check-supported-list \ %_sourcedir %buildroot/lib/modules/$KERNELRELEASE; then %if %supported_modules_check exit 1 %endif echo "Consistency check error: please update supported.conf." fi %ifarch s390 s390x if [ -x "$(which dwarfextract 2>/dev/null)" -a \ -f %buildroot/boot/Kerntypes-$KERNELRELEASE ] ; then find %buildroot -name "*.ko" > kofiles.list dwarfextract %buildroot/boot/Kerntypes-$KERNELRELEASE -C kofiles.list fi %endif # Also put the resulting file in $obj_dir/$cpu_arch/%build_flavor # so that kernel-source%variant + kernel-%build_flavor is sufficient # for building modules that have modversions as well. obj_dir=usr/src/linux-${KERNELRELEASE%%-%build_flavor}%variant-obj # Table of types used in exported symbols (for modversion debugging). %_sourcedir/modversions --pack . > %buildroot/boot/symtypes-$KERNELRELEASE if [ -s %buildroot/boot/symtypes-$KERNELRELEASE ]; then gzip -9 %buildroot/boot/symtypes-$KERNELRELEASE else rm -f %buildroot/boot/symtypes-$KERNELRELEASE fi # Some architecture's $(uname -m) output is different from the ARCH # parameter that needs to be passed to kbuild. Create symlinks from # $(uname -m) to the ARCH directory. [ -e %buildroot/$obj_dir/%_target_cpu ] \ || ln -sf $cpu_arch %buildroot/$obj_dir/%_target_cpu # We were building in %my_builddir/linux-%srcversion, but the sources will # later be installed in /usr/src/linux-%srcversion-%source_rel. Fix up the # build symlink. rm -f %buildroot/lib/modules/$KERNELRELEASE/{source,build} ln -s /usr/src/linux-${KERNELRELEASE%%-%build_flavor} \ %buildroot/lib/modules/$KERNELRELEASE/source ln -s /$obj_dir/$cpu_arch/%build_flavor \ %buildroot/lib/modules/$KERNELRELEASE/build # Abort if there are any undefined symbols msg="$(/sbin/depmod -F %buildroot/boot/System.map-$KERNELRELEASE \ -b %buildroot -ae $KERNELRELEASE 2>&1)" if [ $? -ne 0 ] || echo "$msg" | grep 'needs unknown symbol'; then exit 1 fi %if %split_packages # Generate the lists of supported and unsupported modules. ( cd %buildroot : > %my_builddir/supported-modules : > %my_builddir/unsupported-modules for module in $(find lib/modules/$KERNELRELEASE -type f -name '*.ko'); do case "$(/sbin/modinfo -F supported $module)" in (yes|external) modname=$(basename $module .ko) deps=$(/sbin/modinfo -F depends $module|tr ',' ' ') echo "$modname: $deps" >> %my_builddir/Makefile.supported echo "/$module" >> %my_builddir/supported-modules ;; (*) echo "/$module" >> %my_builddir/unsupported-modules ;; esac done ) add_dependent_modules() { local modules_dep=$1 xargs make -rRs -f <(echo -e '%:\n\t@echo $@' ; cat $modules_dep) } modules_dep=%buildroot/lib/modules/$KERNELRELEASE/modules.dep # Make sure that no supported modules depend on any unsupported modules. dependent_unsupported_modules=$( OUT=$(mktemp) sed -e 's/:.*//g' < %my_builddir/Makefile.supported | \ xargs make -rRsk -f %my_builddir/Makefile.supported > $OUT sed -ne '/No rule/s/^.*No rule to make target//p' < $OUT | tr -d "\`'" ) if [ -n "$dependent_unsupported_modules" ]; then echo "The following unsupported modules are used by supported modules:" echo "$dependent_unsupported_modules" echo "Please fix supported.conf." if [ ! -e %_sourcedir/IGNORE-UNSUPPORTED-DEPS ]; then exit 1 fi fi # Compute the list of base modules: modules that core modules depend on # implicitly are also core modules. grep -f %my_builddir/grep-for-base-modules %my_builddir/supported-modules \ | add_dependent_modules $modules_dep > %my_builddir/base-modules # All supported modules which are not core modules belong in %name. comm -3 <(sort %my_builddir/supported-modules) \ <(sort %my_builddir/base-modules) \ | tr -d ' '> %my_builddir/main-modules %else ( cd %buildroot find lib/modules/$KERNELRELEASE -type f -name '*.ko' -printf '/%%p\n' ) > %my_builddir/base-modules %endif # generate symsets mkdir -p %my_builddir/{base,main,extra}-symsets for f in %my_builddir/{base,main,unsupported}-modules; do if [ -f "$f" ]; then sed 's:^/:%buildroot/:' "$f" > "$f-br" fi done reference= if test -d %my_builddir/kabi/$cpu_arch/symsets-%build_flavor; then $reference="--reference=%my_builddir/kabi/$cpu_arch/symsets-%build_flavor" fi %_sourcedir/symsets.pl --generate-symsets \ $reference \ --symvers=Module.symvers \ --modules=%my_builddir/base-modules-br \ --output-dir=%my_builddir/base-symsets %if %split_packages %_sourcedir/symsets.pl --generate-symsets \ $reference \ --modules=%my_builddir/main-modules-br \ --required-modules=%my_builddir/base-modules-br \ --output-dir=%my_builddir/main-symsets %_sourcedir/symsets.pl --generate-symsets \ $reference \ --modules=%my_builddir/unsupported-modules-br \ --required-modules=%my_builddir/base-modules-br \ --required-modules=%my_builddir/main-modules-br \ --output-dir=%my_builddir/extra-symsets %endif # check for kabi changes KABI=0 if [ -n "$reference" ]; then %_sourcedir/symsets.pl --check-kabi \ $reference \ --commonsyms=%my_builddir/kabi/commonsyms \ --usedsyms=%my_builddir/kabi/usedsyms --severities=%my_builddir/kabi/severities \ --max-badness=%tolerate_kabi_changes || KABI=$? fi if [ $KABI -ne 0 ]; then echo "kABI changes of badness $KABI exceed the maximum allowed badness" \ "of %tolerate_kabi_changes. Please try to avoid the kABI changes." if [ ! -e %my_builddir/kabi/$cpu_arch/ignore-%build_flavor -a \ ! -e %_sourcedir/IGNORE-KABI-BADNESS ]; then echo "Create a file IGNORE-KABI-BADNESS in the kernel-source" \ "directory to build this kernel even though its badness is" \ "higher than allowed for an official kernel." exit 1 fi # Indicate the ABI badness in build result emails. echo "KABI BADNESS $KABI" > %_rpmdir/%_arch/mbuild_subject.tag fi symsets=%my_builddir/symsets-$KERNELRELEASE mkdir -p $symsets find %my_builddir/{base,main,extra}-symsets -type f \ | xargs --replace='{}' cp '{}' $symsets/ tar c -C ${symsets%/*} ${symsets##*/} \ | gzip -9 \ > %buildroot/boot/symsets-$KERNELRELEASE.tar.gz # Set up some module aliases install -d -m 755 %buildroot/etc/modprobe.d/ install -m 644 %_sourcedir/module-renames %buildroot/etc/modprobe.d/ make clean rm -f source find . -type f -o -type l |sed -e "s,^\.,/$obj_dir/%cpu_arch_flavor," \ > %my_builddir/kernel-devel.files fi add_dirs_to_filelist() { local filelist filelist=$(cat "$@") echo "$filelist" # Below, we do this: # - remove filelist macros # - remove last pathname component # - generate all parents and make the list unique # - skip directories owned be other packages # - add the %dir prefix (double-escaped for find and rpm) echo "$filelist" \ | sed -re 's:%%%%[a-z]+(\([^)]+\))? ?::g' \ | sed -re 's:/[^/]+$::' \ | sed -nre ':a; p; s:/[^/]+$::; ta' \ | sort -u \ | sed -r -e '\:^(|/boot|/etc|/lib(/modules|/firmware)?|/usr(/src)?)$:d' \ | sed -e 's:^:%%%%dir :' } # Collect the file lists. { cd %buildroot cat <<-EOF /boot/initrd-%version-%release-%build_flavor %%%%ghost /boot/initrd /boot/vmlinuz-%version-%release-%build_flavor %%%%ghost /boot/vmlinuz /boot/System.map-%version-%release-%build_flavor EOF # Add the auto-generated (by mkdumprd) kdump initrd to %ghost so that # the file gets removed when uninstalling the kernel. echo '%%%%ghost /boot/initrd-'${KERNELRELEASE}'-kdump' touch $RPM_BUILD_ROOT/boot/initrd-${KERNELRELEASE}-kdump if [ $CONFIG_MODULES = y ]; then find lib/modules/$KERNELRELEASE \ -type d -o \ \( -path '*/modules.*' ! -path '*/modules.order' \) \ -printf '%%%%%%%%ghost /%%p\n' -o \ -name '*.ko' -prune -o \ -printf '/%%p\n' cat %my_builddir/base-modules echo '%%%%config /etc/modprobe.d/module-renames' fi test -d lib/firmware/$KERNELRELEASE && \ find lib/firmware/$KERNELRELEASE \ -type d -o \ -printf '/%%p\n' if [ -e .%_docdir/%name ]; then echo "%%%%doc %_docdir/%name" fi } | add_dirs_to_filelist > %my_builddir/kernel-base.files %if %split_packages add_dirs_to_filelist %my_builddir/main-modules > %my_builddir/kernel-main.files add_dirs_to_filelist %my_builddir/unsupported-modules > %my_builddir/kernel-extra.files %endif # Hardlink duplicate files automatically (from package fdupes): It doesn't save # much, but it keeps rpmlint from breaking the package build. %fdupes $RPM_BUILD_ROOT %preun -f preun.sh %postun -f postun.sh %pre -f pre.sh %post -f post.sh %if %split_packages %files -f kernel-main.files %else %files -f kernel-base.files %endif %defattr(-, root, root) %package base Summary: Base kernel package License: GPL Group: System/Kernel Url: http://www.kernel.org/ AutoReqProv: on Provides: %name-base_%_target_cpu = %version-%release Requires(pre): coreutils awk Requires(post): module-init-tools Requires(post): perl-Bootloader Requires(post): mkinitrd %ifarch %ix86 Conflicts: libc.so.6()(64bit) %endif %description base Dummy description. %preun base -f preun-base.sh %postun base -f postun-base.sh %pre base -f pre-base.sh %post base -f post-base.sh %if %split_packages %files base -f kernel-base.files %defattr(-, root, root) %endif %package extra Summary: Unsupported kernel modules License: GPL Group: System/Kernel Url: http://www.kernel.org/ AutoReqProv: on Provides: %name-extra_%_target_cpu = %version-%release Requires: %{name}_%_target_cpu = %version-%release Requires(pre): coreutils awk Requires(post): module-init-tools Requires(post): perl-Bootloader Requires(post): mkinitrd Supplements: packageand(product(SUSE_SLED):%{name}_%_target_cpu) Supplements: packageand(product(openSUSE):%{name}_%_target_cpu) %ifarch %ix86 Conflicts: libc.so.6()(64bit) %endif %description extra Dummy description. %preun extra -f preun-extra.sh %postun extra -f postun-extra.sh %pre extra -f pre-extra.sh %post extra -f post-extra.sh %if %split_packages %files extra -f kernel-extra.files %defattr(-, root, root) %endif %ifarch s390x %if ! %build_vanilla %package man Summary: The collection of man pages generated by the kmsg script. Group: System Environment/Kernel %description man This package includes the man pages that have been generated from the kmsg message documentation comments. %files man %defattr(-,root,root) /usr/share/man/man9/* %endif %endif %package devel Summary: The development environment needed to build KMPs Group: Development/Kernel Requires: kernel-source%variant AutoReqProv: on %description devel Dummy description. %files devel -f kernel-devel.files %defattr(-,root,root) /boot/config-* /boot/symsets-* /boot/symtypes-* /boot/symvers-* /boot/vmlinux-*gz

On Wednesday 07 January 2009 23:31:45 Jeff Mahoney wrote:

[...] In the past month or so I've put some effort into making it easier to do what you're looking to do. The first set of patches remove almost all of the @VAR@ processing in favor of using RPM variables. The result is that you'll be able to add a new flavor by simply changing the %build_flavor variable definition in the beginning of the file and adding a kernel configuration file.

That change is relatively straightforward, and it already makes is a lot easier to create a new flavor by hand: The current kernel-binary.spec.in already contains a %build_flavor definition; we only need to use this definition instead of the old @NAME@ and @FLAVOR@ (which become kernel-%build_flavor and %build_flavor). Can't we simply change that, even right now? Andreas -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org