[opensuse-kernel] kernel-docs package
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In going through the openSUSE kernel bug queue, I ran across one against kernel-docs. The spec file for that package is... entertaining. It starts off by doing a cp -a /usr/src/linux* into the build dir. That might've been a good idea at one point, but it's hardly one anymore. I propose that we make kernel-docs a linked package to the kernel-source package and BuildRequires the kernel-source package. The documentation can be generated with a make -C $SRC O=$PWD instead, negating the need to copy _anything_. Making it a linked package means that the version numbers get set automatically by mkspec. Right now, the kernel-docs package is version 2.6.3 but built against whatever kernel-source is in the repo. - -Jeff diff --git a/rpm/kernel-docs.spec.in b/rpm/kernel-docs.spec.in new file mode 100644 index 0000000..d7ff3b1 - --- /dev/null +++ b/rpm/kernel-docs.spec.in @@ -0,0 +1,97 @@ +# +# spec file for package kernel-docs@VARIANT@ (Version @RPMVERSION@) +# +# Copyright (c) 2009 SUSE LINUX Products GmbH, Nuernberg, Germany. +# +# All modifications and additions to the file contributed by third parties +# remain the property of their copyright owners, unless otherwise agreed +# upon. The license for this file, and modifications and additions to the +# file, is the same license as for the pristine package itself (unless the +# license for the pristine package is not an Open Source License, in which +# case the license is the MIT License). An "Open Source License" is a +# license that conforms to the Open Source Definition (Version 1.9) +# published by the Open Source Initiative. + +# Please submit bugfixes or comments via http://bugs.opensuse.org/ +# + +# norootforbuild + +%include %_sourcedir/kernel-spec-macros + +Name: kernel-docs +BuildRequires: docbook-toys docbook-utils ghostscript_any libjpeg-devel texlive transfig xmlto xorg-x11-devel +BuildRequires: kernel-source = @RPMVERSION@ +Url: http://www.kernel.org/ +License: GPL v2 or later +Group: Documentation/Man +AutoReqProv: on +Version: @RPMVERSION@ +%if %using_buildservice +Release: @RELEASE_PREFIX@<RELEASE> +%else +Release: @RELEASE_PREFIX@0 +%endif +Summary: Kernel Documentation +BuildArch: noarch +BuildRoot: %{_tmppath}/%{name}-%{version}-build +Source: kernel-spec-macros + +%description +These are the PDF documents and man pages (section 9) built from +thecurrent kernel sources. + + + +%prep +cp -av /etc/texmf/web2c/texmf.cnf . +cat << EOF >> texmf.cnf +main_memory.pdfjadetex = 2500000 +hash_extra.pdfjadetex = 70000 +max_strings.pdfjadetex = 120000 +save_size.pdfjadetex = 10000 +EOF +%setup -T -c + +%build +# use texmf.cnf from local source +export TEXMFCNF=$RPM_BUILD_DIR +export LANG=en_US +make -C /usr/src/linux-%{version}-%{release_major} O=$PWD -k -i mandocs %{?jobs:-j%jobs} +make -C /usr/src/linux-%{version}-%{release_major} O=$PWD -k -i pdfdocs %{?jobs:-j%jobs} + +%install +rm -rf $RPM_BUILD_ROOT +install -d $RPM_BUILD_ROOT/%{_mandir}/man9 +# filter out obscure device drivers - they clutter up the rpm and don't add any real value +find Documentation/DocBook/ -name '*.9.gz' | +egrep -v 'man/(sis[69]|rio|fsl|struct_rio|RIO|mpc85|set_rx_mode|mdio_(read|write)|mii_ioctl|mca_|z8530|nand|sppp|piix|(read|write)_zs)' | +while read i ; do + cp $i $RPM_BUILD_ROOT/%{_mandir}/man9 +done +install -d $RPM_BUILD_ROOT/usr/share/doc/kernel +cp -a Documentation/DocBook/*.pdf $RPM_BUILD_ROOT/usr/share/doc/kernel || true +if [ -d Documentation/kdb ] ; then + for i in Documentation/kdb/*.m* ; do + k=`basename $i` + k=${k/man/9} + k=${k/mm/9} + cp $i $RPM_BUILD_ROOT/%{_mandir}/man9/$k + done +fi + +ln -s /usr/share/man/man9/request_threaded_irq.9.gz $RPM_BUILD_ROOT/usr/share/man/man9/request_irq.9.gz + +cp -a /usr/src/linux-%{version}-%{release_major}/{COPYING,CREDITS,MAINTAINERS,README,REPORTING-BUGS} . + +%clean +rm -rf $RPM_BUILD_ROOT + +%files +%defattr(-,root,root) +%doc COPYING CREDITS MAINTAINERS README REPORTING-BUGS +%{_mandir}/man9/* +%docdir /usr/share/doc/kernel +/usr/share/doc/kernel + +%changelog diff --git a/rpm/kernel-source.spec.in b/rpm/kernel-source.spec.in index f3e160c..b951db9 100644 - --- a/rpm/kernel-source.spec.in +++ b/rpm/kernel-source.spec.in @@ -77,12 +77,13 @@ Source52: kernel-source%variant.changes Source53: kernel-source.spec.in Source54: kernel-binary.spec.in Source55: kernel-syms.spec.in - -Source56: config.sh - -Source57: compute-PATCHVERSION.sh - -Source58: old-packages.conf - -Source59: arch-symbols - -Source60: package-descriptions - -Source61: kernel-spec-macros +Source56: kernel-docs.spec.in +Source60: config.sh +Source61: compute-PATCHVERSION.sh +Source62: old-packages.conf +Source63: arch-symbols +Source64: package-descriptions +Source65: kernel-spec-macros Source100: config.tar.bz2 Source101: patches.arch.tar.bz2 Source102: patches.drivers.tar.bz2 diff --git a/rpm/mkspec b/rpm/mkspec index 7e49c36..905835c 100755 - --- a/rpm/mkspec +++ b/rpm/mkspec @@ -82,6 +82,9 @@ for my $flavor (sort keys(%flavor_archs)) { # kernel-source.spec do_spec('source', "kernel-source$variant.spec", %macros); +# kernel-docs.spec +do_spec('docs', "kernel-docs$variant.spec", %macros); + # kernel-syms.spec { my $requires = ""; @@ -128,7 +131,7 @@ sub parse_config_conf { sub read_spec_templates { my %res; - - for my $template qw(binary source syms) { + for my $template qw(binary source syms docs) { xopen(my $fh, '<', "$dir/kernel-$template.spec.in"); my @lines = <$fh>; $res{$template} = join("", @lines); - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAksgRuIACgkQLPWxlyuTD7Lf1ACfQ6RjQwPewBHgZEzd3wPYCV90 A74An1E+M/7BP6qAjWU/J68TDJoLq+bN =gKhO -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Thursday 10 December 2009 01:54:58 Jeff Mahoney wrote:
In going through the openSUSE kernel bug queue, I ran across one against kernel-docs. The spec file for that package is... entertaining. It starts off by doing a cp -a /usr/src/linux* into the build dir. That might've been a good idea at one point, but it's hardly one anymore.
I propose that we make kernel-docs a linked package to the kernel-source package and BuildRequires the kernel-source package. The documentation can be generated with a make -C $SRC O=$PWD instead, negating the need to copy _anything_. Making it a linked package means that the version numbers get set automatically by mkspec. Right now, the kernel-docs package is version 2.6.3 but built against whatever kernel-source is in the repo.
definitely a good idea. I was part of those that started this package and at that time I did the copying around of the sources to be able to patch things whenever "make docs" broke because some source file processor was not able to grok the source code anymore. If this is more visible to the kernel hackers (which I assume it will by being in the same source directory) these issues can be fixed directly instead of hacking around "postmortem" ... -- with kind regards (mit freundlichem Grinsen), Ruediger Oertel (ro@novell.com,ro@suse.de,bugfinder@t-online.de) ---------------------------------------------------------------------- Linux MacBookRudi 2.6.32-3-desktop #1 SMP PREEMPT 2009-12-04 00:41:46 +0100 x86_64 Key fingerprint = 17DC 6553 86A7 384B 53C5 CA5C 3CE4 F2E7 23F2 B417 SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On 10.12.2009 09:32, Ruediger Oertel wrote:
On Thursday 10 December 2009 01:54:58 Jeff Mahoney wrote:
I propose that we make kernel-docs a linked package to the kernel-source package and BuildRequires the kernel-source package. The documentation can be generated with a make -C $SRC O=$PWD instead, negating the need to copy _anything_. Making it a linked package means that the version numbers get set automatically by mkspec. Right now, the kernel-docs package is version 2.6.3 but built against whatever kernel-source is in the repo.
definitely a good idea. I was part of those that started this package and at that time I did the copying around of the sources to be able to patch things whenever "make docs" broke because some source file processor was not able to grok the source code anymore. If this is more visible to the kernel hackers (which I assume it will by being in the same source directory) these issues can be fixed directly instead of hacking around "postmortem" ...
Due to the way the kotd scripts work (no support for dependent builds), it won't be built as part the kotd. How long does it take to generate the docs? Maybe we could build it directly from kernel-source.spec. But let's import it to the kernel git first and then discuss possible improvements. Michal -- 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 On 12/10/2009 08:33 AM, Michal Marek wrote:
On 10.12.2009 09:32, Ruediger Oertel wrote:
On Thursday 10 December 2009 01:54:58 Jeff Mahoney wrote:
I propose that we make kernel-docs a linked package to the kernel-source package and BuildRequires the kernel-source package. The documentation can be generated with a make -C $SRC O=$PWD instead, negating the need to copy _anything_. Making it a linked package means that the version numbers get set automatically by mkspec. Right now, the kernel-docs package is version 2.6.3 but built against whatever kernel-source is in the repo.
definitely a good idea. I was part of those that started this package and at that time I did the copying around of the sources to be able to patch things whenever "make docs" broke because some source file processor was not able to grok the source code anymore. If this is more visible to the kernel hackers (which I assume it will by being in the same source directory) these issues can be fixed directly instead of hacking around "postmortem" ...
Due to the way the kotd scripts work (no support for dependent builds), it won't be built as part the kotd. How long does it take to generate the docs? Maybe we could build it directly from kernel-source.spec. But let's import it to the kernel git first and then discuss possible improvements.
I wonder if there are ways that we can creatively work on dependent builds. The kernel binaries should be dependent on kernel-source as well, and mbuild is the only reason they're not. The build service can handle it. People using rpmbuild can use it. It's mbuild that's the issue. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkshLNQACgkQLPWxlyuTD7JEfQCgj42TmZ14LIVwKL9Qfe0Bhyo4 Oz0An1KiJyMRSx+ebt5rRL57ACvPqYbM =fQFo -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
Jeff Mahoney napsal(a):
I wonder if there are ways that we can creatively work on dependent builds. The kernel binaries should be dependent on kernel-source as well,
Why?
and mbuild is the only reason they're not. The build service can handle it. People using rpmbuild can use it. It's mbuild that's the issue.
But is it practical then? I mean to build a kernel, you just build a kernel-$flavor.spec. If you make kernel-$flavor.spec dependent on kernel-source, then you always have to first build kernel-source.spec (which spends good amount of time in rpmlint), and what's worse, if you forget this step, then the next build will pick up whatever kernel-source package is in the repository. If it's the duplication between kernel-source.spec and kernel-$flavor.spec that bothers you, then it's IMO easier to factor out the source unpacking and patching to a separate script. Michal -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
Le jeudi 10 décembre 2009 21:47, Michal Marek a écrit :
Jeff Mahoney napsal(a):
I wonder if there are ways that we can creatively work on dependent builds. The kernel binaries should be dependent on kernel-source as well,
Why?
and mbuild is the only reason they're not. The build service can handle it. People using rpmbuild can use it. It's mbuild that's the issue.
But is it practical then? I mean to build a kernel, you just build a kernel-$flavor.spec. If you make kernel-$flavor.spec dependent on kernel-source, then you always have to first build kernel-source.spec
... which is a sane thing to do anyway, as you "must" distribute kernel-source with any binary kernel package in order to comply with the GPL.
(which spends good amount of time in rpmlint),
... peanuts compared to the build time of actual kernel flavors.
and what's worse, if you forget this step, then the next build will pick up whatever kernel-source package is in the repository. If it's the duplication between kernel-source.spec and kernel-$flavor.spec that bothers you, then it's IMO easier to factor out the source unpacking and patching to a separate script.
Michal
-- Jean Delvare Suse L3 -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
Jean Delvare napsal(a):
Le jeudi 10 décembre 2009 21:47, Michal Marek a écrit :
Jeff Mahoney napsal(a):
I wonder if there are ways that we can creatively work on dependent builds. The kernel binaries should be dependent on kernel-source as well, Why?
and mbuild is the only reason they're not. The build service can handle it. People using rpmbuild can use it. It's mbuild that's the issue. But is it practical then? I mean to build a kernel, you just build a kernel-$flavor.spec. If you make kernel-$flavor.spec dependent on kernel-source, then you always have to first build kernel-source.spec
... which is a sane thing to do anyway, as you "must" distribute kernel-source with any binary kernel package in order to comply with the GPL.
How does this relate to build ordering?
(which spends good amount of time in rpmlint),
... peanuts compared to the build time of actual kernel flavors.
On a machine with lots of cpus, the non-paralelized parts like rpmlint and find-debuginfo.sh are the most annoying part. We try to optimize this, not add more. Nevertheless, I most concerned about this:
and what's worse, if you forget this step, then the next build will pick up whatever kernel-source package is in the repository.
It's already non-trivial to build your custom kernel and KMPs against it, let's not add this complexity to the actual kernel build. Michal -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
Le vendredi 11 décembre 2009 12:35, Michal Marek a écrit :
Jean Delvare napsal(a):
Le jeudi 10 décembre 2009 21:47, Michal Marek a écrit :
Jeff Mahoney napsal(a):
and mbuild is the only reason they're not. The build service can handle it. People using rpmbuild can use it. It's mbuild that's the issue. But is it practical then? I mean to build a kernel, you just build a kernel-$flavor.spec. If you make kernel-$flavor.spec dependent on kernel-source, then you always have to first build kernel-source.spec
... which is a sane thing to do anyway, as you "must" distribute kernel-source with any binary kernel package in order to comply with the GPL.
How does this relate to build ordering?
My personal experience is: given two thinks that must be done, one you like doing and one you don't like doing, chances to see the latter done are much higher if the former happens to depend on it in some way. Seriously, it doesn't strictly relate to the build ordering, but I don't think the build order really matters anyway.
(which spends good amount of time in rpmlint),
... peanuts compared to the build time of actual kernel flavors.
On a machine with lots of cpus, the non-paralelized parts like rpmlint and find-debuginfo.sh are the most annoying part. We try to optimize this, not add more.
If this really bothers you, maybe work on rpmlint and find-debuginfo.sh to let them parallelize their work? Oh, and I doubt find-debuginfo.sh takes that long for the kernel-source package ;) rpmlint, yes, certainly. -- Jean Delvare Suse L3 -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
participants (4)
-
Jean Delvare -
Jeff Mahoney -
Michal Marek -
Ruediger Oertel