<---- template headericclude ----->
How to build your own RPMS (including kmods)
FedoraForum.org - Fedora Support Forums and Community
Page 1 of 13 12311 ... LastLast
Results 1 to 15 of 194
  1. #1
    Join Date
    Dec 2004
    Location
    Canada
    Age
    32
    Posts
    9,221
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Post How to build your own RPMS (including kmods)

    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!
    Last edited by Firewing1; 13th October 2006 at 12:10 AM.
    [+] My open source software and blog
    [+] Some of my howtos: (for full list, click here)

  2. #2
    Join Date
    Dec 2004
    Location
    Canada
    Age
    32
    Posts
    9,221
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    %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
    Last edited by Firewing1; 25th October 2006 at 10:21 PM.
    [+] My open source software and blog
    [+] Some of my howtos: (for full list, click here)

  3. #3
    Join Date
    Dec 2004
    Location
    Canada
    Age
    32
    Posts
    9,221
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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)
    [+] My open source software and blog
    [+] Some of my howtos: (for full list, click here)

  4. #4
    Join Date
    Aug 2004
    Posts
    55
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.
    it is by my will alone that I set my mind in motion

  5. #5
    Join Date
    Dec 2004
    Location
    Canada
    Age
    32
    Posts
    9,221
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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
    [+] My open source software and blog
    [+] Some of my howtos: (for full list, click here)

  6. #6
    Join Date
    Jul 2006
    Location
    Sao Paulo, SP - Brazil
    Age
    43
    Posts
    712
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote 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

  7. #7
    Join Date
    Dec 2004
    Location
    Canada
    Age
    32
    Posts
    9,221
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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
    [+] My open source software and blog
    [+] Some of my howtos: (for full list, click here)

  8. #8
    Join Date
    Oct 2004
    Location
    London, UK
    Posts
    4,995
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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

  9. #9
    Join Date
    Jul 2006
    Location
    Sao Paulo, SP - Brazil
    Age
    43
    Posts
    712
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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

  10. #10
    Join Date
    Dec 2004
    Location
    Canada
    Age
    32
    Posts
    9,221
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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
    [+] My open source software and blog
    [+] Some of my howtos: (for full list, click here)

  11. #11
    Join Date
    Jul 2006
    Location
    Sao Paulo, SP - Brazil
    Age
    43
    Posts
    712
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote 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 Im wrong: if Im 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?

    Ill follow your advices and count, as always, with your great assistance.

    Thanks!
    Duli

  12. #12
    Join Date
    Dec 2004
    Location
    Canada
    Age
    32
    Posts
    9,221
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Duli
    Hum, ok, I get it. So the problem is more into the compiling stuff. But then, correct if Im wrong: if Im 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?
    Ill 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
    [+] My open source software and blog
    [+] Some of my howtos: (for full list, click here)

  13. #13
    Join Date
    Jul 2006
    Location
    Sao Paulo, SP - Brazil
    Age
    43
    Posts
    712
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote 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

  14. #14
    Join Date
    Apr 2006
    Posts
    10
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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?

  15. #15
    Join Date
    Jul 2007
    Posts
    49
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    awesome...

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

Page 1 of 13 12311 ... LastLast

Similar Threads

  1. F8 kmods for ndiswrapper and nvidia complete with build instrutions
    By leigh123linux in forum Guides & Solutions (Not For Questions)
    Replies: 36
    Last Post: 23rd September 2007, 06:11 PM
  2. build rpms
    By jim in forum Using Fedora
    Replies: 0
    Last Post: 30th April 2005, 05:50 AM
  3. How to build *-devel-rpms?
    By Der Hanseat in forum Using Fedora
    Replies: 5
    Last Post: 23rd December 2004, 01:56 AM

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
[[template footer(Guest)]]