Using the openSUSE Build Service, you can provide software packages for most popular Linux distros using one single service. Rather than maintaining separate systems to build packages, you can take advantage of the openSUSE Build Service and let it do most of the work.

To learn how to leverage the build service, join the openSUSE community on April 4th and 5th on IRC to hone your package building skills. The Packaging Days II event will be held on Freenode at #opensuse-buildservice. Community members will be standing by to provide support and answer questions about using the build service and creating packages.

Find out more about the Packaging Days II event at: http://en.opensuse.org/Packaging/Packaging_Day

Packages for openSUSE 10.2 and 10.3 can be obtained from my openSUSE build farm account at : home:jefferyfernandez. If you encounter any bugs in the package or the application itself, please report them at: qBittorrent Bug-tracker. Happy torrenting

qBittorrent Home: http://www.qbittorrent.org

urpmi.addmedia jeffery http://jefferyfernandez.id.au/RPMS with hdlist.cz

The list of available packages on the repository can be seen by accessing this list

linux-gate.so.1 =>  (0xffffe000)
libtorrent.so.0 => /usr/lib/libtorrent.so.0 (0xb7e98000)
libQtXml.so.4 => /usr/lib/qt4/lib/libQtXml.so.4 (0xb7e61000)
libQtGui.so.4 => /usr/lib/qt4/lib/libQtGui.so.4 (0xb7a43000)
libpng.so.3 => /usr/lib/libpng.so.3 (0xb7a1d000)
libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0xb7a14000)
libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0xb79fc000)
libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0xb79f4000)
libXrender.so.1 => /usr/X11R6/lib/libXrender.so.1 (0xb79ea000)
libXrandr.so.2 => /usr/X11R6/lib/libXrandr.so.2 (0xb79e6000)
libXcursor.so.1 => /usr/X11R6/lib/libXcursor.so.1 (0xb79dd000)
libXinerama.so.1 => /usr/X11R6/lib/libXinerama.so.1 (0xb79da000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb7971000)
libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0xb7941000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0xb7932000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0xb7866000)
libQtCore.so.4 => /usr/lib/qt4/lib/libQtCore.so.4 (0xb7753000)
libz.so.1 => /lib/libz.so.1 (0xb7740000)
libdl.so.2 => /lib/libdl.so.2 (0xb773c000)
libpthread.so.0 => /lib/i686/libpthread.so.0 (0xb76ea000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb760d000)
libm.so.6 => /lib/i686/libm.so.6 (0xb75e8000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb75dd000)
libc.so.6 => /lib/i686/libc.so.6 (0xb74ae000)
libboost_filesystem.so.1 => /usr/lib/libboost_filesystem.so.1 (0xb749f000)
libboost_date_time.so.1 => /usr/lib/libboost_date_time.so.1 (0xb7492000)
libboost_thread.so.1 => /usr/lib/libboost_thread.so.1 (0xb7486000)
libXfixes.so.3 => /usr/X11R6/lib/libXfixes.so.3 (0xb7481000)
libexpat.so.0 => /usr/lib/libexpat.so.0 (0xb7461000)
/lib/ld-linux.so.2 (0xb7f9e000)
librt.so.1 => /lib/i686/librt.so.1 (0xb744e000)

qbittorrent being a QT based application and as you can see it clearly depends on libQtXml, libQtGui and libQtCore. Based on this information, I can now add those dependencies for the qbittorrent package alongside the libtorrent library. Most of the other libs are sub-dependant libraries.

NOTE: This also means qbittorrent is not statically linked to any of the above libraries. So if libQtGui was statically linked in qbittorrent, then it won’t appear in the above list and you don’t have to worry about it being a dependency for the qbittorrent package.

So I embarked on the journey of building my own package for qt4. I managed to get hold of a spec file from the Mandriva CVS repository and then was shocked to see that it contained 27 sub-packages. There was no way I was going to sit down and do a trial and error build for this project. So I did some googling around and found this cool tool which could possibly do all the hard work for you. Its called checkinstall.

Checkinstall is a software which helps you in building an RPM from the last step of the install process of a package you have compiled. For example when you compile a software with ./configure; make; make install, you are actually compiling and installing a software onto your system. The third command “make install” is when you are actually installing the binaries into the appropriate location.

To use Checkinstall, you first run ./configure and make to build your program, then run checkinstall. Checkinstall will run then run “make install” (or whatever you tell it to run) and keep track of every file modified by this installation. In the end it will ask you for the package specific details like package name, source location, dependencies, etc. When “make install” is done, checkinstall will create a Slackware, RPM or Debian package depending on which distro you are using checkinstall. Now this package can be installed like any other package on your system.

The only downside is that it does not prepare you a source-package nor does it create sub-packages… ofcourse I am asking for too much intelligence there. The good side is you don’t have to worry about your spec file failing due to some silly mistake you made, especially when you are building a monstor package like qt. So if you are looking for the easy way out to build RPM packages for yourself, give checkinstall a go.

Cabinet (.CAB) files are a form of archive, which Microsoft use to distribute their software, and things like Windows Font Packs. The cabextract program unpacks these files.

And why do I have this here? … because I required it to run ie4linux on WINE

Download Cabextract

To make this happen, RPM needs to use your own environment definitions rather that of the root user. You need to override the default macros RPM uses. The most important one is the %_topdir (which by default would point to /usr/src/redhat) macro. There are a few more customizations you can make to speed up your Spec file generation. Open up a shell and create a rpmmacros file:

vim ~/.rpmmacros

Now add the following definitions into it, replacing it with your name, email address and system home directory

%distribution Mandriva Linux
%packager Jeffery Fernandez <developer @jefferyfernandez.id.au>
%vendor http://www.jefferyfernandez.id.au

%_topdir /home/jeffery/redhat
%_tmppath /home/jeffery/redhat/tmp

%_signature gpg
%_gpg_name 2473E75A
%_gpg_path /home/jeffery/.gnupg

%prefix /usr/local/

The first three lines define some macros you would use in a Spec file. This saves you from re-typing them into the Spec file every time you make one. Next comes the important bit, the topdir and tmppath macros.

As a consequence of re-defining the %_topdir macro, RPM will need the package building directory structure available in the topdir location you have defined. You can make this structure by executing the following:

mkdir -p ~/redhat/{BUILD,RPMS/{i386,i486,i586,i686,noarch},SOURCES,SPECS,SRPMS,tmp}

This will create a heirarchy of folders in your home directory (similar to the one found at /usr/src/redhat) which look like:

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

The next three lines are required if you intend to sign your packages with a GPG key. If you don’t have one yet, you can ignore them. More about GPG signing of RPMS in an other topic

Once you have finished this, you should be ready to build packages as a normal user. Ok.. and if you are wondering what the prefix macros does….. then my answer is I am still researching about it. Quick google tells me that it is meant to define where the packages are installed. To me that doesn’t sound right. anyone have suggestions?

This trusted public key may belong to a vendor or an individual itself and be part of a “web of trust“. By being part of a trusted group we can make sure that any packages signed (GPG signed) by the owner of that key is authentic.

Having said that, here is how you would import a key for your RPM trust database. To import my GPG signed key, you can execute the following shell command as root user:
rpm --import http://www.jefferyfernandez.id.au/jeffery.gpg
Having executed that command now makes the packages signed by me a trusted package, simply because I belong to the “web of trust”. So now you can safely install (if you wish to ) any packages I have uploaded onto this site.

To verify if a package you have downloded matches the trusted key to the packages signature, execute the following command:

rpm --checksig packagename.rpm

which should give you an “OK” result similar to:

packagename.rpm: (sha1) dsa sha1 md5 gpg OK

And finally to list all the trusted keys in the RPM trust db execute:

rpm -q gpg-pubkey --qf '%{name}-%{version}-%{release} --> %{summary}\\n'