Skip to content

OLPC School Server Packaging Release 0.3

This release is my final release for OLPC school server packaging. I am going to solve problems left in ds-backup and xs-activity-server packages.

In ds-backup release 0.2, rpmlint reports:

“ds-backup-server.noarch: E: script-without-shebang /var/www/ds-backup/”.

Howerver, when I check file, the first line comments that the file is not a cgi script. The file then will stay in a path dedicated for executables, so the rpmlint gives the above complaint. To solve the problem, I use git to create a patch which including the shebang line in file. My step listed below:

1. download release 0.2 rpm package:

rpm -i ds-backup-0.11.5.g536d1d6-3.fc17.src.rpm

2. uncompress the source tarball file:

cd ~/rpmbuild/SOURCES/
tar xvf ds-backup-0.11.5.g536d1d6.tar.bz2

3. create the patch using git tool and trace the change:

cd ds-backup-0.11.5.g536d1d6
git init
git add *
git commit -a -m “Initial commit”
vi server/ (in vi add shebang line: #!/usr/bin/bash”)
git commit -a -m “Add Sheband line in file”
git format-patch HEAD^1

4. now I got a patch file named I moved the file to SOURCES directory and added the patch to the spec file:

mv ..
cd ~/rpmbuild/SPEC
vi ds-backup.spec

5. rebuilding the package would fix the problem.

rpmbuild -ba ds-backup.spec

Another issue exists in my two packages. The upstream tarball missed in source website. I hold them temporarily in my site to avoid rpmlint complaint, now I am change its location to fit Fedora packaging guideline. I only need change the source tag to using the tarball name directly and give some comments like this:

# You can get this tarball by a link from:
Source0: ds-backup-0.11.5.g536d1d6.tar.bz2

Rebuilt these two packages and rpmlint check, seems good. Built them in koji:

cd ~/rpmbuild/SRPMS/
Koji build f17 –scratch xs-activity-server-0.3.5.g3b1d13b-4.fc17.src.rpm
koji build f17 –scratch ds-backup-0.11.5.g536d1d6-4.fc17.scr.rpm


Release 0.3:


Koji build result:


Review Result


Bugzilla list

OLPC School Server Packaging Release 0.2

In the release 0.2, I am going to try to fix all error and major warning that rpmlint reported in release 0.1.

To the permission errors like:

ds-backup-server.noarch: E: non-standard-dir-perm /var/lib/ds-backup/recentclients 0700L
A standard directory should have permission set to 0755. If you get this
message, it means that you have wrong directory permissions in some dirs
included in your package.

I change the permission 700 in spec file to 755 to fix these kind of complaint:

%attr(755, apache, apache) %dir %{_localstatedir}/lib/ds-backup/recentclients
%attr(755, nobody, nobody) %dir %{_localstatedir}/lib/ds-backup/completion

To the warning like:

xs-activity-server.noarch: W: incoherent-version-in-changelog 0.2 [‘0.3.5.g3b1d13b-2.fc17’, ‘0.3.5.g3b1d13b-2’]
The latest entry in %changelog contains a version identifier that is not
coherent with the epoch:version-release tuple of the package.

I change the log tag to:

* Tue Nov 20 2012 Zhiping Yu <> 0.3.5.g3b1d13b-3

The change fixed the warning in rpmlint report.

Another complint from rpmlint is like:

xs-activity-server.src: W: invalid-url Source0: HTTP Error 404: Not Found
The value should be a valid, public HTTP, HTTPS, or FTP URL.

Because the tarballs are not exist in the source url, as a temporary resolution, I upload the bz2 files form ~/rpmbuild/SOURCE directory to my website. After the successful build, maybe someone can upload the original tarballs to the source url.

The review processes are cumbersome, I find that using fedora-review tool can help me a little. After install fedora-review, type like:

/usr/bin/fedora-review -r –name ds-backup-0.11.5.g53d1d6-3.fc17.src.rpm

Such, I got a review report. However, I still need check a banch of items manually base on my experience.

Release 0.2 link:


SPEC file link:


Review report:


Red Hat Bugzilla Review Link:

xs-rsync — Closed due to duplicate requirement

OLPC School Server Packaging Release 0.1

The release 0.1 goals are Releasing initial versions of the xs-activity-server, xs-rsync, and ds-backup packages.

Orignal rpm test result:

0.1 Release (Corrected some errors and eliminated some warning information):

My release rpm test result:

Python Lab

1. Check python version
     >>>$python -V

2. List imported python modules

3. Get help

4. Import new modules
     >>>import math
     >>>from math import      sqrt
     >>>from math import *

5. My python program

6. Test result

How to create a RPM package repository for yum

Creating the Repositor

After signing my packages, I can create repository for use with yum. (Notice: To follow my steps, you must have completed all steps in my last Blog, “Signing RPMs”)

Before start, let me check if the createrepo package has installed in my system.

$ rpm -q createrepo

OK, now I can create the repository follow the steps:

1. Copy my RPMs to another directory:

$ mkdir ~/repodir
$ cp ~/rpmbuild/RPMS/* ~/repodir

2. Sign these RPMs in ~/repodir directory

$ cd ~/repodir
$ rpm –addsign *

3. Create repository:

$ createrepo .

4. Copy all content to a website so others can download these packages.


5. Create my repository file in /etc/yum.repos.d ( I need change to superuser ):

$ su
# vi /etc/yum.repos.d/

6. Copy my gpg public key file to /etc/pki/rpm-gpg/ directory. ( The key file has been created in my last Blog. )

# cp /home/zyu26/ /etc/pki/rpm-gpg/

7. Now, in my regular user account, check yum list:

In superuser account, check if I can install these packages:

Repository-Release RPM

To make it easier for others to access my repository, I need create a reporitory-release RPM, execute steps below:
1. Create a tarball which including my repo file and GPG key:

$ cp /etc/yum.repos.d/sbr600.repo ~/rpmbuild/SOURCES/
$ cp /etc/pki/rpm-gpg/ ~/rpmbuild/SOURCES/
$ cd ~/rpmbuild/SOURCES/
$ tar cvf sbr600repo.tar sbr600.repo
$ gzip sbr600repo.tar

2. Build release RPM:

$ cd ~/rpmbuild/SPECS/
$ rpmdev-newspec sbr600release
$ vi sbr600release.spec

$ rpmbuild -ba sbr600release.spec

3. Put the built release package to my website so that people can access it.


Digital signature ( RPM Signing )

This time, I will show how to create digital signature and sign my RPM packages.

To sign RPM packages, we need preparate our Fedora first:

# yum install rpm-sign gnupg

1. Create a GPG key:

$ gpg –gen-key

Follow the steps to create public and private key.

2. Add %_gpg_name macro into ~/.rpmmacro:

$ vi ~/.rpmmacros
%_gpg_name “”

3. Go to SRPMS directory and sign my packages:

$ rpm –addsign diffutils-3.2-7.fc17.src.rpm
$ rpm –addsign which-2.20-4.fc17.src.rpm

4. Create ASCII public key file and check my signature:

a. First, export my public key to a text file:

$ gpg –export –armour > ~/
$ cat ~/
Version: GnuPG v1.4.12 (GNU/Linux)


b. Import the public key to RPM DB:

sudo rpm –import ../home/zyu26/

c. Now, I can check my signature:

$ rpm –checksig which-2.20-4.fc17.src.rpm diffutils-3.2-7.fc17.src.rpm
which-2.20-4.fc17.src.rpm: rsa sha1 (md5) pgp md5 OK
diffutils-3.2-7.fc17.src.rpm: rsa sha1 (md5) pgp md5 OK

By signing the package, users know where the software comes from. So they can decide whether or not download it.

How to Use Koji

It’s time to learn how to use koji.

The Koji is a useful build system which can build PRM packages for different architectures.
First, we need install koji client:

# yum install fedora-packager

Because I have installed fedora-packager already, I don’t need do it again.
Then, I need my certificate to use koji to build packages:

$ /usr/bin/fedora-packager-setup

Follow the steps and input my Fedora Account System user name and some passwords, I got my certificate file: fedora-browser-cert.p12 in my home directory.
Open a browser( in my case, I use firefox), import the certifcate into “Your Certificates” tab to use the koji web interface.

Here, according the Using Koji page, I should be able to login, but I can’t. My browser still indicates “Waiting for…”. Anyway, there is no effect to continue my building.

Now, I start to build my first package – which.

$ cd ~/rpmbuild/SRPMS
$ koji build f17 –scratch which-2.20-4.f17.src.rpm

The target system is Fedora 17 in i386 and x86_64 architectures.

Opening Koji website, I can see the result.

How about my second package – diffutils? Let me try it. Issue command:

 $ cd ~/rpmbuild/SRPMS
 $ koji build f17 — scratch diffutils-3.2-7.f17.src.rpm

I am lucky again. However, if you suffer some problems, you can open the build.log file from koji website by click your failed task. You should find the clue about the reason of the build failed.

Koji is amazing, I don’t need actually build packages in the physical machines to check the builds is good for those architectures. It will save us large amount of money and time.