How to build your own RPMS (including kmods)

**Firewing1** · 7th October 2006, 03:50 AM

Hello,
I've had a few people asking how to build Livna modules for development kernels, so here's the next guide

If I can, I'd like for this to be a massive howto so I'm going to reserve the next 3 posts, because I'll need them later on as I add to this... But in the mean while, I'll write the best part first - Rebuilding kernel modules!

Overview on the RPM format and specfiles in general

If you'd like some general information on RPM, or just a very good reference, please see this page:
http://www.rpm.org/RPM-HOWTO/

In short, when you build RPMS you get two of them:
- RPMs (called binary RPMS or binary packages)
- SRPMs (called source RPMS or source packages)

The normal RPMs contain the compiled files, meaning they're ready to be installed and used right away. This is what you want 99% of the time, and it's what for example 'yum' grabs when you install things. However, if you want to build your own RPMs, you're going to require those SRPMs because they contain the source files - non-compiled stuff - that you can modify if needed and use again to rebuild your own custom RPM.

All RPMS, both SRPMs and RPMs are built through spec files. A spec file is basically a special file with specific format and commands that define what your package is, what files it owns, what files are non-replaceable (configuration) files, which things to install where, it's name, etc. It's how RPM can keep track of everything so well. Learning the format of specfiles and how they work is crucial to building RPMs.

Specfiles

I'm going to show you the general outline of a specfile, and also show you the little bits and pieces that may not seem big, but if followed make it a Fedora Extras-acceptable package. Besides that, following the FE guidelines make a pretty clean and overall nice specfile, and therefore RPMs are build more cleanly.

I'm not sure about you, but I like seeing examples, it helps quite a bit when adapting to new things and concepts. You'll find that a lot of my example come from fwbackups, and feel free to even use my specfile as a base for yours if you'd like.

This the typical, minimal specfile:

Code:

Name:
Version:
Release:        1%{?dist}
Summary:

Group:
License:
URL:
Source0:
BuildRoot:      %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)

BuildRequires:
Requires:

%description


%prep
%setup -q


%build
%configure
make %{?_smp_mflags}


%install
rm -rf $RPM_BUILD_ROOT
make install DESTDIR=$RPM_BUILD_ROOT


%clean
rm -rf $RPM_BUILD_ROOT


%files
%defattr(-,root,root,-)
%doc


%changelog

Name - Name of your package (Ususally same name as what you're packaging)

Version - The version of what you're packaging

Release - Your release. You use release to make changes to a package when the actual version doesn't change - ex. a new patch must be applied, a bug is fixed in the specfile, etc. This is why you always see the version format like this: [version]-[release] - eg 2.16-1, 2.16-2, so on - In both cases the packaged program is still version 2.16, but in the latter a bug was fixed or something else that requried a new package to be made. So the release tag was bumped up by one. When you up the version, you set the 'Release' tag back to 1. The %{?dist} part just adds .fc# to the end of the release, where # is the fedora release it's built for.

Summary: - A very short summary of your package. Only a few words.

Group: - The group your package fits into. To see a full list of groups, type in a terminal:

Code:

cat `rpm -ql rpm | grep GROUPS$` | less

License: - The license of your package. Typically 'GPL'.

URL: - The URL of the program you're packaging, with the http:// prefix. For example, because fwbackups is now hosted at http://www.diffingo.com, I could enter that there. If you decided to package your own Wine packages, then put

Code:

URL: http://www.winehq.com

Source0: - The source tarball for your package. It's better to have this as a full URL that works. No broken links. For example:

Code:

Source0: http://www.diffingo.com/downloads/fwbackups/fwbackups-1.42.1.tar.gz

If you want a even cleaner spec, incorporate your Version tag into the Source0 tag by using %{version}. For example:

Code:

Source0: http://www.diffingo.com/downloads/fwbackups/fwbackups-%{version}.tar.gz

You can also add your own sources and add another Source line, like this:

Code:

Source1: MySourceTarballOrFile
Source2: MySourceTarballOrFileAgain

This is especially useful for adding in .desktop files (so that your program appears in the system menus) and also for applying patches not available in upstream.

*** Note: "Cleaner" specs won't really make a difference in terms of the package outputted - But it's much easier to be read by others and not to mention you'll thank yourself later when you need to edit the specfile again. ***

Patch0: - An optional tag that you can use to apply patches. In the same way as source, you can add more and more with Patch1 and Patch2. Note that after the Patch#: statement you need to reference a file or a %{Source#} that reffers to the patch file.

BuildRoot: Leave this tag as shown above. It's just the directory you're assigning RPM to use when actually building the RPM, and Fedora likes to have it formatted like that line.

BuildRequires: - What packages are needed to rebuild the SRPM of this package?

Requires: - What the package requires to run. Please note that there are exceptions that you shouldn't include in this list.

%description - The longer descritption of your package. Don't make it too long, a few sentences should do. Also, don't put more than 80 characrters per line of the description - That's what line breaks are for!

*** Read me before!
Now we're getting into the complex part of the rpm specfile, so here's some more info...
***

RPM uses macros, which are useful for creating high-grade RPMs that across distributions.
A macro is basically a special tag that RPM replaces with a directory on the system - But each distribution can define their own tags. So, if you use macros as often as possible, you have a better chance of not only making the same RPM work on future versions of Fedora but on other distributions. Here's the list of Fedora's macros:

Code:

%_prefix          /usr
%_exec_prefix          %{_prefix}
%_bindir          %{_exec_prefix}/bin
%_sbindir          %{_exec_prefix}/sbin
%_libexecdir          %{_exec_prefix}/libexec
%_datadir          %{_prefix}/share
%_sysconfdir          %{_prefix}/etc
%_sharedstatedir          %{_prefix}/com
%_localstatedir          %{_prefix}/var
%_libdir          %{_exec_prefix}/lib
%_includedir          %{_prefix}/include
%_oldincludedir          /usr/include
%_infodir          %{_prefix}/info
%_mandir          %{_prefix}/man

You can use a macro in a regular command, like this:

Code:

install -D -p -m755 usr/sbin/fwbackups ${RPM_BUILD_ROOT}%{_sbindir}/fwbackups

RPM will repalace the macro with the real path when building.

%prep - The prep section, stuff that happens before building starts. Unpacking the source tarballs goes here, along with any patches you need to apply.
%setup -q - Unpacks the tarballs and changes the working directory to them.

patch0 -b .patch0 - Again, optional but used to apply the patch referenced by Patch0. You apply more patches in the same way with '%patch1 -b .patch1', and so on.

%build - The build step.
%configure - (I think) Configure you package (./configure) with the normal Fedora directories passed as args. Can be commented if your program doesn't need a ./configure.
make %{?_smp_mflags} - Run 'make' the program, paying attention to SMP flags. Again, can be commented if your program doesn't need to 'make'.

%install - The section used to place the commands used to install files on your system.
rm -rf $RPM_BUILD_ROOT - You always want to clean your buildroot as the first thing in %install to remove any trace of a previous build or anything else lying around.

Now, a few examples of things in the %install section:

Code:

install -d -p -m755 ${RPM_BUILD_ROOT}%{_bindir}

Create /usr/bin in for the RPM buildroot, with permissions of '755'. You NEVER want to simply do:

Code:

install -d -p -m755 %{_bindir}

As this affects the real filesystem. (It actually tries to make /usr/bin on the system, which exists and you'll get an error)

*** NOTE: When installing files, you install everything to the buildroot, which in turn and it gets packaged into the binary RPMs.[/b] Besides that if something messes up, you haven't modified the whole system but only the buildroot. The contents of a directory is disposable, the system isn't. ***

Code:

install -D -p -m644 etc/fwbackups/fwbackups.conf ${RPM_BUILD_ROOT}%{_sysconfdir}/fwbackups/fwbackups.conf

This installs the etc/fwbackups/fwbackups.conf file from the tarball into [buildroot]/etc/fwbackups/fwbackups.conf - Which in turn becomes /etc/fwbackups/fwbackups.conf in the outputted RPMs.

make install DESTDIR=$RPM_BUILD_ROOT - Again, can be commented out if your program doesn't need a 'make install'.

%clean - Cleaning after building.
rm -rf $RPM_BUILD_ROOT - Clean your buildroot after you're done building stuff!

**Firewing1** · 7th October 2006, 03:51 AM

%files - A list of the files owned by the RPM. Remember that two packages shouldn't own the same directory! For example, you may have a file in /usr/bin but it doesn't mean you have to own the entire /usr/bin directory. Just own your package's file in /usr/bin.

%defattr(-,root,root,-) - Set the default attributes on files.

Now, make that list. Here's a few examples:

Code:

%dir %{_sysconfdir}/fwbackups

Let's say your package needs to own the /etc/fwbackups directory, this is how you do it.

Code:

%{_bindir}/fwbackups

It owns /usr/bin/fwbackups.

Code:

%{_datadir}/fwbackups/*

A neat trick that makes it own everything in /usr/share/fwbackups - Recursive, too.
This works well because since we build everything in a buildroot, telling it even '%{_datadir}/*' isn't everything in /usr/share but everything in /usr/share in your buildroot. Useful

Code:

%config(noreplace) %{_sysconfdir}/fwbackups/fwbackups.conf

Don't replace /etc/fwbackups/fwbackups.conf. Will result in .rpmnew/.rpmsave files.

%doc - List the documentation files - some examples are COPYING, LICENCE, README.

Code:

%doc COPYING LICENSE README

%changelog - You have to add a changelog entry for each change you make to the package, even if it's just a simple rebuild for the next 'Core and nothing's changed. Just put that:

Code:

* 3-letter-day 3-letter-month Day Year Name Lastname <e.mail@domain.com> version-release
- Rebuilt for new Fedora Core

You can follow that format for any date, and log. Other examples:

Code:

* Thu Sep 21 2006 Stewart Adam <s.adam@diffingo.com> 1.42-5
- Add %%requires: pygtk2-libglade

We use %%requires because it's like the backslash for Bash - Using %requires in changelog would make RPM see two %requires and get confused. %%requires safely escapes it. The same applies for all macros - For the %changelog section, don't use %{_libdir} but %%{_libdir}.

Code:

* Thu Aug 15 2006 Stewart Adam <s.adam@diffingo.com> 1.42-0
- Rebuild using sample .spec file from Fedora Extras
- Update to version 1.42 (see CHANGELOG file for details on version changes)

Simple enough

Setup your system for RPM building

** IMPORTANT NOTE **
This section is vital. No matter which step you'd like to start at, this needs to be done only once before starting.

This is just setting up your user for RPM building, and only needs to be done once.
(Not once per step, once until you erase your account and need to start over completely.)

Code:

echo '%_topdir %(echo $HOME)/rpmbuild' > .rpmmacros
mkdir rpmbuild
cp -a /usr/src/redhat/* rpmbuild
su -
yum install fedora-rpmdevtools rpm-build mock

One should also note it's unsafe to build RPMS as root, this now allows you to build RPMS as your regular user.
** END IMPORTANT NOTE **

Overview on building your own RPMS from scratch

-- to come, but start with this --

Code:

su -
yum install rpmdevtools
exit
cd ~/rpmbuild/SPECS
fedora-newrpmspec

And now start by editing the new specfile.

Overview on rebuilding existing SRPMS

-- to come, but in short --

Code:

rpmbuild --rebuild SRPM_HERE.src.rpm

Overview on rebuilding kernel modules

This one breaks down to a few steps:

(Pre). You must have the kernel-devel (the kernel source) package installed, with the version that you want to build against. For example, if I would like to build a module for kernel 2.6.18-1.2746.fc6, I have to have kernel-devel-2.6.18-1.2746.fc6 installed.

Install kernel-devel with:

Code:

su -
yum install kernel-devel
exit

1. Download the kernel modules SRPMs and any other SRPMs needed
For example in the case of graphics drivers, you need the kernel module AND xorg SRPM packages

2. Install the SRPM packages:

Code:

rpm -ihv *src*.rpm

Their source and specs are now in your ~/rpmbuild/SOURCES and ~/rpmbuild/SPECS directories, respectively.

3. Edit the specfile, if needed.
Common use is changing the kernel version to build a module against

4. Build the RPM:

Code:

rpmbuild -ba --target=[architecture] ~/rpmbuild/SPECS/specname.spec

where [architecture] is the arch you'd like to build for. Some examples are i386, i586, i686, x86_64, etc...

(After) Successfully build RPMs go into the ~/rpmbuild/RPMS/[arch] folder, and your generated SRPMs into ~/rpmbuild/SRPMS

Little tricks when rebuilding Livna modules
- You can find the Livna module sources at: http://rpm.livna.org/fedora/
So the SRPMS are in http://rpm.livna.org/fedora/yourfedoraversion/SRPMS
- Currently, the 'fc5' SRPMS are more updated than the 'development' ones are. So I would use those when re-building kernel module RPMS.
- The names of the modules may be reversed. Example, rather than kmod-nvidia the source package may be named nvidia-kmod.
- When rebuilding, you may get errors about kernel devel packages being required. Try adding this option to the rpmbuild command:

Code:

--define 'kvariants ""'

It worked for me when rebuilding the nVidia modules.

Examples

Here's an example of how to modify the Livna nVidia RPMs, following the same steps I wrote above
fglrx users, you can use this same basic theory and apply it to the fglrx packages, it will work too.
(pre):

Code:

yum install kernel-devel

It installs these two packages:
(1) kernel-2.6.18-1.2726.fc6 (2) kernel-devel2.6.18-1.2726.fc6
)I'm on fc6 / development repos, it's why yum grabs the fc6 kernels and not the fc5 ones...)

1. Download:
http://rpm.livna.org/fedora/5/SRPMS/...87_FC5.src.rpm
http://rpm.livna.org/fedora/5/SRPMS/...1.lvn5.src.rpm

2. Install:

Code:

rpm -ihv nvidia-kmod-1.0.8774-1.2.6.17_1.2187_FC5.src.rpm xorg-x11-drv-nvidia-1.0.8774-1.lvn5.src.rpm

3. Modify the spec file:

Code:

gedit ~/rpmbuild/SPECS/nvidia-kmod.spec&

I change:

Code:

%{!?kversion: %define kversion 2.6.17_1.2187_FC5}

to read:

Code:

%{!?kversion: %define kversion 2.6.18-1.2726.fc6}

because I want to build a module for kernel-2.6.18-1.2726.fc6.

4. Build:
** Commands are bold, results are normal **

Code:

rpmbuild -ba xorg-x11-drv-nvidia.spec

It succeeds. So let's try the kernel module:

Code:

rpmbuild -ba nvidia-kmod.spec
error: Architecture is not included: i386

OK, so let's try with a different architecture; `uname -m` output's your system's architecture:

Code:

rpmbuild -ba nvidia-kmod.spec --target=`uname -m`
error: Failed build dependencies:
        kernel-smp-devel-i686 = 2.6.18-1.2726.fc6 is needed by nvidia-kmod-1.0.9625-1.2.6.18_1.2741.fc6.i686
        kernel-xen0-devel-i686 = 2.6.18-1.2726.fc6 is needed by nvidia-kmod-1.0.9625-1.2.6.18_1.2741.fc6.i686
        kernel-kdump-devel-i686 = 2.6.18-1.2726.fc6 is needed by nvidia-kmod-1.0.9625-1.2.6.18_1.2726.fc6.i686

There go those kernel requires errors I was talking about in the 'Tips' section. Let's try messing around with --define and kvariants:

Code:

rpmbuild -ba nvidia-kmod.spec --target=`uname -m` --define 'kvariants ""'

And now it builds. All that's left is to install the new RPMs you've just made!

Participate in the Fedora Extras!

You're encouraged to help out and participate in the Fedora Extras project. If you'd like to help out by adding your RPMS to the Extras, please see these two pages to start:
http://fedoraproject.org/wiki/Extras/Contributors
http://fedoraproject.org/wiki/Packag...viewGuidelines

**Firewing1** · 7th October 2006, 03:51 AM

Reserving post 3...
(The max characters when posting is 10,000, and often my big howtos are too big for one post. It's why I post after the main message, so I can edit this out later and replace it with content)

**sardaukar_siet** · 13th October 2006, 11:09 AM

Kinda old tool, but checkinstall (http://asic-linux.com.mx/~izto/checkinstall/) can create RPMs and DEBs and also Slackware tgz's I believe. use for all my builds from source to keep everything registered in the package database.

**Firewing1** · 13th October 2006, 10:02 PM

You're right, it can - But they're not always perfect, I'm sure they don't abide to the Fedora Extras standards and also some packages refuse to checkinstall.
Firewing1

**Duli** · 7th February 2007, 01:15 AM

Originally Posted by sardaukar_siet

Kinda old tool, but checkinstall (http://asic-linux.com.mx/~izto/checkinstall/) can create RPMs and DEBs and also Slackware tgz's I believe. use for all my builds from source to keep everything registered in the package database.

Hello,

I'm able to build the RPMS with checkinstall with no problem. But when I try to install the package, I receive this error:

error: unpacking of archive failed on file ... cpio: MD5 sum mismatch

Any clues?

Thanks
Duli

**Firewing1** · 7th February 2007, 01:34 AM

Hmmm... Not sure - In that case, make sure the program has a 'make uninstall' rule and if it does, use 'make install' and archive that source directory somewhere. When you want to get rid of it, make uninstall.
Firewing1

**sideways** · 7th February 2007, 02:36 AM

That MD5 error is a known bug http://asic-linux.com.mx/~izto/checkinstall/faq.php

Also checkinstall has a few limitations (statically linked binaries aren't handled!)

Thanks for this, I'm sure after the initial learning curve the procedure becomes routine.

yet another thread to bookmark

**Duli** · 7th February 2007, 03:31 AM

Okay, guys, firewing and sideways.

Thanks for answering.

If you install the package with "--nomd5" option, it goes ok. I guess it's a temporary workaround.

Anyway, I think it will take a lot of hours to learn how to build packages like firewing has described (do you confirm that?). This is a task I wish to accomplish. Till then, checkinstall could do a little help...

Thanks a lot,
Duli

**Firewing1** · 7th February 2007, 05:49 AM

It does take a while, but it's not the actually building - Once you read the Fedora Extras guidelines briefly, and take a look at a few example specs to get an idea, you'll get the hang really fast. What's hard is getting it to build properly, with the right sources, patches, paths, %configure options, etc.
Firewing1

**Duli** · 7th February 2007, 02:05 PM

Originally Posted by Firewing1

It does take a while, but it's not the actually building - Once you read the Fedora Extras guidelines briefly, and take a look at a few example specs to get an idea, you'll get the hang really fast. What's hard is getting it to build properly, with the right sources, patches, paths, %configure options, etc.
Firewing1

Hum, ok, I get it. So the problem is more into the compiling stuff. But then, correct if I´m wrong: if I´m able to correctly build/compile a program, then the packaging proccess will be easier?

I mean, the simple building is easier than the package building?

I´ll follow your advices and count, as always, with your great assistance.

Thanks!
Duli

**Firewing1** · 7th February 2007, 10:58 PM

Originally Posted by Duli

Hum, ok, I get it. So the problem is more into the compiling stuff. But then, correct if I´m wrong: if I´m able to correctly build/compile a program, then the packaging proccess will be easier?
I mean, the simple building is easier than the package building?
I´ll follow your advices and count, as always, with your great assistance.
Thanks!
Duli

Yup! If all builds well, then you can basically take an existing spec you have lying around, change it a little, and it should be OK.
Firewing1

**Duli** · 8th February 2007, 12:01 AM

Originally Posted by Firewing1

Yup! If all builds well, then you can basically take an existing spec you have lying around, change it a little, and it should be OK.
Firewing1

Hey, now you've gave me good news!
Thanks!
Duli

**Pilal** · 20th February 2007, 06:55 AM

With my custom built kernel, I am able to make RPMs from the SRC.RPMs. But when I try to install with
rpm -ivh ... it complaints that the kernel version is wrong (it lists the kernel as a missing dependency) . If I try to install with yum localinstall, it still wants to
download the matching kernel . Is it actually possible to use the livna drivers with a custom built kernel?

**StevenMedley** · 7th July 2007, 06:28 PM

awesome tutorial, easy to understand, bookmarking for later... till then ill review a few specs.

How to build your own RPMS (including kmods)

Thread Tools

Search Thread

Display

How to build your own RPMS (including kmods)

awesome...

Similar Threads

F8 kmods for ndiswrapper and nvidia complete with build instrutions

build rpms

How to build *-devel-rpms?

Tags for this Thread

Posting Permissions

User Tag List