rpm building

[Ice9]

Is there a comprehensive howto somewhere for me to learn how to build rpm packages from source tarballs?
I've googled it over and over but I haven't been able to find a source that goes deep enough into details for me to understand it completely.

Or is this too far over my head and should I stick to build them from src.rpm?

Thing is I've come accross several applications lately which I haven't been able to find in pre-compiled format.
I'd like to be able to install them with all the advantages of rpm, and why not contribute to the community and make them available if they turn out to bee good enough quality.

[Tux]

http://www.rpm.org/RPM-HOWTO/
http://freshrpms.net/docs/fight/

They're a good start, but working through any problems you come across helps the learning process
Those are the best links my brain can provide at the moment, i'm sure void has some more. If you get stuck, ask here.

[Ice9]

Thanks Tux, the howto presented by rpm.org wasn't what I was looking for, especially the part about the specfile wasn't very clear but the freshrpms link looks pretty good.

And you can be sure that I'm gonna come here and ask for help if I can't figure stuff out on my own
It would be nice to finally be able to give something back to the community!

Edit:
I found this resource, looks pretty clear too (at least from an amateur's point of view)
http://newbie.linuxbe.org/linux/rpm/seneca-rpm.html

[Void Main]

I used "The Fight" over at FreshRPMS to learn. I am by no means an expert but I have a little repository going:

http://voidmain.is-a-geek.net/files/RPMS/

I hesitate to put anything large or popular out there as I don't really have the bandwidth. I'm thinking it would be nice if someone had some spare bandwidth and would let us create our own repository. Or maybe contribute to one of the existing repositories. It would be cool if we could all consolidate down to one giant reliable repository like Debian has.

I have a couple of suggestions about building RPMS that I think are important and I believe Matthias stresses in his document at FreshRPMS. The first thing is that you shouldn't be root when you build RPMS. I create a subdirectory tree under my home directory:

Code: Select all

~/redhat/BUILD
~/redhat/RPMS
~/redhat/RPMS/athlon
~/redhat/RPMS/i386
~/redhat/RPMS/i486
~/redhat/RPMS/i586
~/redhat/RPMS/i686
~/redhat/RPMS/noarch
~/redhat/SOURCES
~/redhat/SPECS
~/redhat/SRPMS


Then I have a ~/.rpmmacros file that contains:

Code: Select all

%packager               Void Main
%distribution           Void Main RPMS
%vendor                 voidmain.is-a-geek.net
%_signature             gpg
%_gpg_name              Void Main
                                                                               
%_topdir                /home/voidmain/redhat
%_tmppath               /var/tmp
                                                                               
%_rpmtopdir             %{_topdir}
%_builddir              %{_rpmtopdir}/BUILD
%_buildhost             voidmain.is-a-geek.net
%_rpmdir                %{_rpmtopdir}/RPMS
%_sourcedir             %{_rpmtopdir}/SOURCES
%_srcrpmdir             %{_rpmtopdir}/SRPMS
%_specdir               %{_rpmtopdir}/SPECS
                                                                               
%_menudir               /usr/lib/menu
%_iconsdir              /usr/share/icons
%_miconsdir             /usr/share/icons/mini
%_liconsdir             /usr/share/icons/large
 
%debug_package          %{nil}


Once you have your RPM building environment set up like above then install a few source RPMS and take a look at the spec files and see how they are put together. You can install source RPMS without being root with either the "rpm -i package.src.rpm" command or the "apt-get source package" command.

Some things I found easy as a starting point is to grab the very latest source for a package in tar.gz format and then grab the latest source RPM available (presuming the tar.gz is newer than than what you can find in RPM format) for that package. Install it "rpm -i package.src.rpm". You should find the original *.tar.gz (or *.tar.bz) source tarball in ~/redhat/SOURCES. Copy your new source tarball into the SOURCES directory and then edit the spec file for the package (found in ~/redhat/SPECS) and update all the version numbers and source tar ball file name in the spec file. Then build the new binary and source RPMS with this command in the SPECS directory:

$ rpmbuild -ba package.spec

This will create the binary RPM(s) in ~/redhat/RPMS/i386 (or whatever arch you are building for) and the new source RPM will end up in ~/redhat/SRPMS. You can view the contents of the package with the usual "rpm" commands like "rpm -qilp package.i386.rpm" or "rpm -qilp package.src.rpm".

I have built a few from scratch but not many. I have hacked Apache slightly and created a couple of my own *.patch files and included them in the spec file for my own custom Apache RPM (httpd-xxx.i386.rpm). That's fun stuff there (not meaning hard, but actually fun).

Some example patch files and spec files:
http://voidmain.is-a-geek.net/files/patches/

There are special sections you can put in the spec file where you can put code to be executed when the RPM is installed and when it is removed. This allows you to stop/start services, add/remove usernames, or any other system changes that may need to happen when you install or remove an RPM.

Once you get the hang of it it's really fun. Hopefully I can answer some of your questions if you have any. Also, hopefully I will learn more in the process because as I said, there is a lot more to know about building RPMs than what I know and I would like to get better at it. The next thing I really need to do is to sign all of my RPMS and put a GPG key out there for people to download/import. I haven't looked into what needs to be done for this but I don't believe it should be too hard.

[Ice9]

Thanks Void Main, I think I'llbe able to at least start learning how to build rpms now that Tux and yourself provided me with some sources.
And I really like the idea of everyone contributing to a single large repository, I know I'd like to be part of such a group once I'm capable of producing quality packages.

The next thing I really need to do is to sign all of my RPMS and put a GPG key out there for people to download/import. I haven't looked into what needs to be done for this but I don't believe it should be too hard.

I find this to be a gigantic pain, the theory behind it is good but you have to make sure people know where to find your gpg key and know how to import it.
When I added the redhat-kde sources to my sources.list I started to have troubles installing software with apt-get, every single time I got an error like "3 unsigned/unknown packages" and it wouldn't install anything.
I know I imported the dag.wiers key but I didn't find any redhat-kde key to import so I had to disable the gpg check in apt.conf to be able to use apt-get again.

I saw a reference to that key a few days ago but I don't remember where (I'd have to search a little bit when I can spare the time).

[Void Main]

Like you said, you don't have to use the key, in fact the apt that I use comes configured to ignore the key regardless (it will spit out a warning, but it still installs the software). Importing a key is very easy and I think I should offer it for those who prefer to install signed packages only. Not that anyone has any reason to trust my packages whether they are signed or not.

[Ice9]

Just a quick update:
I started out yesterday night with the latest source of krusader (which is the best file-manager ever in my opinion) and ran into a lot of trouble.
First ./configure ended on

Code: Select all

checking for X... configure: error: Can't find X includes. Please check your installation and add the correct paths!

I looked it up and installed the correct devel packages.
Next I got

Code: Select all

configure: WARNING: libjpeg not found. disable JPEG support.
checking for Qt... configure: error: Qt (>= Qt 3.1 (20021021)) (headers and libraries) not found. Please check your installation!


So, again, I looked it up, installed the Qt-devel packages, didn't do it, installed a lot of libs and finally got it to work until

Code: Select all

WARNING:  KDEDIR enviroment variable is empty! Check the krusader FAQ!

So I did

Code: Select all

$ echo $KDEDIR


and it returned /opt/kde

so I

Code: Select all

export KDEDIR=/opt/kde3


run ./configure again and it keeps returning the same message.

Finally I edited /etc/profile and added

Code: Select all

if [ -d /opt/kde3 ]; then
   KDEDIR=/opt/kde3
   export KDEDIR
fi

rebooted and now I get

Code: Select all

Krusader Project:
-----------------
  Source code location: .
  C Compiler:           gcc
  C Compiler flags:     -ansi -W -Wall -pedantic -Wchar-subscripts -Wshadow -Wpointer-arith -Wmissing-prototypes -Wwrite-strings -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -O2   -Wformat-security -Wmissing-format-attribute
  C++ Compiler:         g++
  prefix:               /opt/kde3
  kde_libraries:        /usr/include/kde
  kde_includes:         /usr/lib
  kde_locale:           /opt/kde3/share/locale
  qt_libraries:         /usr/lib/qt-3.3/lib
  qt_includes:          /usr/lib/qt-3.3/include
  KDEDIR:               /opt/kde3
  QTDIR:                /usr/lib/qt-3.3
  Install path:         /opt/kde3/bin
  krusader version:     1.30
  krusader binary:      /opt/kde3/bin/krusader     (after 'make install')


Thank you for using Krusader

Good - your configure finished. Start make now


A bit of a lengthy post I know, but this is just so you know I'm busy trying out the stuff you pointed me to yesterday

[Ice9]

Ok, I'm a bit further now, make went ok.
Then I did

Code: Select all

make install prefix=/home/ycluckers/Install/

to install krusader as a user in an Install directory I created for that purpose.
Ok as well.

Then i started with the tricky part, the specfile, this is the part that I have found to be obscure at the very least, so I adapted the krusader.spec file I found in the tarball to more or less reflect what the freshrpms tutorial said.
Here it is

Code: Select all

# derived from spec file by Shie Erlich & Rafi Yanai

%define name   krusader
%define version 1.30
%define release RH9_KDE_3.2.1

Name: %{name}
Summary: A twin-panel file manager based on the MC design.
Version: %{version}
Release: RH9_KDE_3.2.1
Source: krusader-1.30.tar.gz
Group: Utilities/System
BuildRoot: %{_tmppath}/%{name}-buildroot
URL: http://krusader.sourceforge.net/
Copyright: GPL
Prefix: /usr
Requires: kdelibs

%description
Krusader is a new "old-school" file manager and ftp client.
It's twin-panel look follows in the footsteps of the great
file managers of old: GNU's Midnight Commander and
the DOS all time favorite Norton Commander.

%prep
rm -rf $RPM_BUILD_ROOT

%setup -q -n %name-%version

%build
export CFLAGS=$RPM_OPT_FLAGS
export CXXFLAGS=$RPM_OPT_FLAGS

%configure
make %{_smp_mflags}

%install
rm -rf %{buildroot}
%makeinstall
KDEDIR=$RPM_BUILD_ROOT%{_prefix} kde_minidir=$RPM_BUILD_ROOT%{_miconsdir}

%find_lang %{name}

%clean
rm -rf %{buildroot}

%post -p /sbin/ldconfig

%postun -p /sbin/ldconfig

%files -f %name.lang
%defattr(-,root,root)
%doc README AUTHORS ChangeLog TODO COPYING krusader.lsm
%doc %{_datadir}/doc/HTML/en/*
%_bindir/*
%_datadir/applnk/Applications/krusader.desktop

%dir %_datadir/apps/krusader/
%_datadir/apps/krusader/*.rc
%_datadir/apps/krusader/*.png
%_datadir/apps/krusader/*.jpg

%dir %_datadir/apps/krusader/icons/
%dir %_datadir/apps/krusader/icons/hicolor/
%dir %_datadir/apps/krusader/icons/hicolor/16x16/
%dir %_datadir/apps/krusader/icons/hicolor/16x16/actions/
%_datadir/apps/krusader/icons/hicolor/16x16/actions/*.png

%dir %_datadir/apps/krusader/icons/hicolor/22x22/
%dir %_datadir/apps/krusader/icons/hicolor/22x22/actions/
%_datadir/apps/krusader/icons/hicolor/22x22/actions/*.png

%dir %_datadir/apps/krusader/icons/hicolor/32x32/
%dir %_datadir/apps/krusader/icons/hicolor/32x32/actions/
%_datadir/apps/krusader/icons/hicolor/32x32/actions/*.png

%changelog
* Wed Mar 31 2004 Ice9
- My first rpm attempt.


This is actually the third version, after I had to change some stuff to fix inconsistencies.
But ... now I'm stuck at

Code: Select all

error: Installed (but unpackaged) file(s) found:
   /usr/lib/kde3/kio_krarc.la
   /usr/lib/kde3/kio_krarc.so
   /usr/share/icons/hicolor/32x32/apps/krusader.png
   /usr/share/icons/hicolor/32x32/apps/krusader2.png
   /usr/share/icons/locolor/16x16/apps/krusader.png
   /usr/share/man/man1/krusader.1.gz
   /usr/share/mimelnk/application/x-ace.desktop
   /usr/share/services/krarc.protocol


RPM build errors:
    Installed (but unpackaged) file(s) found:
   /usr/lib/kde3/kio_krarc.la
   /usr/lib/kde3/kio_krarc.so
   /usr/share/icons/hicolor/32x32/apps/krusader.png
   /usr/share/icons/hicolor/32x32/apps/krusader2.png
   /usr/share/icons/locolor/16x16/apps/krusader.png
   /usr/share/man/man1/krusader.1.gz
   /usr/share/mimelnk/application/x-ace.desktop
   /usr/share/services/krarc.protocol


And I can't seem to find anything usefule other than "fix your specfile" or

Code: Select all

echo "%_unpackaged_files_terminate_build 0" >> /etc/rpm/macros

to tell rpm not to abort on unpackaged files.

If I do this, will the rpm have missing files like icons and stuff?
Can I actually do something else to package these files myself?

Edit:
I included

Code: Select all

%define _unpackaged_files_terminate_build 0

in my specrfile and the package built!!!!
One more question though, the rpm generated is in the i386 folder and has i386 in the name, I suspect it has to do with the RPM_OPT_FLAGS but I'm not sure and I don't know how to modify this.
I have a Centrino 1.4GHz so I shouyld be able to build for the i686, or am I missing something?

[Void Main]

Whenever I had files that were installed but unpackaged I added them to the "files" section of the SPEC file. Here's an "extreme" example with several files sections for several resulting RPMs from one SPEC file:

http://voidmain.is-a-geek.net/files/pat ... ree86.spec

When you built the RPM with that unpackaged_files* flag do the files listed actually get included in the RPM? I would think they wouldn't. If you want them included add them to the files section. They look like files that should be included to me, but I'm not sure about that. Personally, I would not add that flag to my macros system wide macros file. In fact I wouldn't add it at all if it will cause important files to not get included in the RPM.

You might also want to add require statements so that a person can't install the RPM without the required dependencies being installed (if anything is required).

Most things are built as i386 RPMS as they will run on any x86 system i386 and above. The only time you might want to created targeted RPMS is if you are building a CPU intensive package, like an engineering app or something. Something where you need to squeeze the last bit of performance you can out of your processor. Many apps do not require the special functions of higher end processors and targeting them for such will be of very little benefit, if any. I think building an *.i386.rpm file for a file manager is just about right.

[Ice9]

You might also want to add require statements so that a person can't install the RPM without the required dependencies being installed (if anything is required).

How would one know what dependencies are required?
And I thought

Code: Select all

Requires: kdelibs


took care of this?
I've seen a couple of requires in the original krusader.spec.

I'm not on my RH9 machine at the moment, I'll look into that tomorrow.

One more question.
My system is quite heavily customized, KDE for instance is a more or less stock KDE now and has little or nothing to do with the Red Hat KDE anymore.
Would that be a problem for other people wanting to install an rpm I made?

Maybe I can upload it to my site if someone with a "regular" RH9 install was willing to test it?

[Void Main]

I try to keep things as stock as possible on the machine I build RPMS on. If you don't you inevidably will compile something against a non-standard library and you will then be contributing to what people call "dependency hell". Of course I don't use that term because for me there is no dependency hell. As far as I am concerned dependencies are a *good* thing. I like to see people who build RPMs and put the extra touch on them to make sure when it is installed, if it is a graphical app that a menu item get added for both KDE and Gnome regardless of whether it is a KDE or a GNOME app. At least if they are building for a Red Hat/Fedora system.

As long as you have someone test them with a stock machine and it works then you should be good. Just make sure when you ask them to test that you give them some test criteria (ask them if the menu items were added if this was suppose to happen, etc).

[Void Main]

Hmm, don't know if you knew this or not but there is already a Fedora RPM for this on the project home:

http://krusader.sourceforge.net/index.php?nav=down.php

You might want to compare your SPEC file with theirs:

http://voidmain.is-a-geek.net/files/misc/krusader.spec

[Ice9]

Is there any online resource that documents how to put that extra touch?

About the "as stock as possible" I suppose it could be a problem then because all the KDE libraries are different on my machine.
I'll try to find someone who still uses RH9 to test the rpm but I don't know anyone off the top of my head.
Any volunteers?
# rpm -i --test should do it for testing purposes, shouldn't it?

[Ice9]

Hmm, don't know if you knew this or not but there is already a Fedora RPM for this on the project home:

http://krusader.sourceforge.net/index.php?nav=down.ph

I know, that was the rpm that I used before upgrading KDE to version 3.2.
After the upgrade krusader didn't work anymore.
I installed the SUSE version and that one worked but there were missing icons in the menus and stuff like that so I figured that for the learning process any source tarball would do it and I tried this one.
With the rpm that I built everytning is mighty fine

[Void Main]

Cool, yeah, unless people have KDE installed just like you then that RPM probably will not work for them. Your first couple of RPMS might seem painful but after you do a few they start to become pretty easy to do (not always though). I try to install install software on my system via RPM only, even if it means I have to build the RPM myself. It makes for a smooth running system. It makes for an easy upgradable system. It makes for an easy verifiable system. And many many more benefits come from having the installed software managed. But you know that. :)

Like in many cases, to find out what needs to be installed to have things show up on your menu it might be best to look at another RPM that includes the menu items. For instance, the switchdesk RPM in my repository:

http://voidmain.is-a-geek.net/files/RPM ... 6.rpm.html

You can see one of the files in the list is:

/usr/share/applications/redhat-switchdesk.desktop

If you examine that menu file you will see it has this line:

Categories=Application;Settings;X-Red-Hat-Extra;

which makes it show up on the Red Hat preferences and system settings menu under "more system settings" and "more preferences".

But you are running a stock KDE installed in different locations so you'll likely need to find the directory where your menu shortcuts go and create one where you want it. Then include it in your RPM. In fact look at the krusader spec file from one of the other distros. It should have a menu file.