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/backup-available.py”.

Howerver, when I check backup-available.py 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 backup-available.py file. My step listed below:

1. download release 0.2 rpm package:

wget http://matrix.seneca.on.ca/~zyu26/olpc/release_0.2/ds-backup-0.11.5.g536d1d6-3.fc17.src.rpm
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/backup-available.py (in vi add shebang line: #!/usr/bin/bash”)
git commit -a -m “Add Sheband line in backup-available.py file”
git format-patch HEAD^1

4. now I got a patch file named 0001-Add-Shebang-line-in-backup-available.py-file.patch. I moved the file to SOURCES directory and added the patch to the spec file:

mv 0001-Add-Shebang-line-in-backup-available.py-file.patch ..
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:
# http://dev.laptop.org/git/users/martin/ds-backup/
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

Done

Release 0.3:

xs-activity-server-0.3.5.g3b1d13b-4.fc17.src.rpm
xs-activity-server.spec
ds-backup-0.11.5.g536d1d6-4.fc17.scr.rpm
ds-backup.spec

Koji build result:

xs-activity-server
ds-backup

Review Result

xs-activity-server
ds-backup

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:

%changelog
* Tue Nov 20 2012 Zhiping Yu <zyu26@myseneca.ca> 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://dev.laptop.org/~douglas/SOURCES/xs-activity-server-0.3.5.g3b1d13b.tar.bz2 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:

xs-activity-server-0.3.5.g3b1d13b-3
xs-rsync-0.6.12.gabc8f49-3
ds-backup-0.11.5.g536d1d6-3

SPEC file link:

xs-activity-server.spec
xs-rsync.spec
ds-backup.spec

Review report:

xs-activity-server
xs-rsync
ds-backup

Red Hat Bugzilla Review Link:

xs-activity-server
ds-backup
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:
xs-activity-server-0.3.5.g3b1d13b-1
xs-rsync-0.6.12.gabc8f49-1
ds-backup-0.11.5.g536d1d6-1

0.1 Release (Corrected some errors and eliminated some warning information):
xs-activity-server-0.3.5.g3b1d13b-2.fc17.src.rpm
xs-rsync-0.6.12.gabc8f49-2.fc17.src.rpm
ds-backup-0.11.5.g536d1d6-2.fc17.src.rpm

My release rpm test result:
xs-activity-server-0.3.5.g3b1d13b-2
xs-rsync-0.6.12.gabc8f49-2
ds-backup-0.11.5.g536d1d6-2

Python Lab

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

2. List imported python modules
     >>>$python
     >>>dir
     >>>dir(__builtins__)

3. Get help
     >>>help
     help>keywords

4. Import new modules
     >>>import math
     or
     >>>from math import      sqrt
     or
     >>>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
createrepo-0.9.9-11.fc17.noarch

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.

diffutils-3.2-7.fc17.i686.rpm
which-2.20-4.fc17.i686.rpm

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/gpgpubkey.pub /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/gpgpubkey.pub ~/rpmbuild/SOURCES/
$ cd ~/rpmbuild/SOURCES/
$ tar cvf sbr600repo.tar sbr600.repo gpgpubkey.pub
$ 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.

sbr600release-1.0-1.fc17.i686.rpm

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 “zyu26@learn.senecac.on.ca”

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 zyu26@learn.senecac.on.ca > ~/gpgpubkey.pub
$ cat ~/gpgpubkey.pub
—–BEGIN PGP PUBLIC KEY BLOCK—–
Version: GnuPG v1.4.12 (GNU/Linux)

mI0EUGBw9wEEAMU6kvOLoosyHV4Ue/5VTkrPsxP3T1uWy54uC/KF4nm6GCRsdVmP
wJtlE1uDAs3tGZjooob0YbGEUufhLd6lS8U5ZMgp24VymICnes+QB9Y/fyLeO6r8
WyCI2I4MpuhwH811kh78nAetrdgcvW4gEgwQgLtm1MW2+xiYrctYSsUfABEBAAG0
L1poaXBpbmcgWXUgKFNCUjYwMCkgPHp5dTI2QGxlYXJuLnNlbmVjYWMub24uY2E+
iLgEEwECACIFAlBgcPcCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEG6V
Of8bMNFC5P8D/RgqMiZezM7fFJ5aXbF68/z3nm6kW8DBwumFMLoT2C3jy0te2Lj0
5n1NEiyghY5yeWuf3Z5QA0B4lNsSKK6fwDLvAH9AddEWTCpYzI9FSo9edHrcdozI
iZGBsBopRdBDrYhtIvdbRfbR5hJ4Y6VeP8M8K2dAm+D6KQqLS1M3KdS4uI0EUGBw
9wEEAMjIQmWPgYKpDYCJffFbnkI/SWj81KAfVAk3nuk+HH3GQuD7p3PjmcTiWR3i
b17e6XqTLkTFsO9KNcGjXDt2ov39OU4YjeTI179gfPc6RARZ+bXTzwHshdW95ov1
htGqBaBxcKPBEVxKqOw9iWR0P/8RnOn/harGVIHgHsgJo91bABEBAAGInwQYAQIA
CQUCUGBw9wIbDAAKCRBulTn/GzDRQo3LBACTl6tZBaE05UAMvxrNzlGYAmYFchs8
1F9AeURPvM80BrjnikI+kodUyHzgoYCg+sYW9SV8s319b93lcoRsbAISTAGz52g0
cOj5p2hU+8yTZZCT4yHuvLhUdkMyI/tOJgfZAekKlPFwiGmoGVLqBccnZPrLNgb9
DazYxdNErdl6Tg==
=Mjop
—–END PGP PUBLIC KEY BLOCK—–

b. Import the public key to RPM DB:

sudo rpm –import ../home/zyu26/gpgpubkey.pub

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 koji.fedoraproject.org…”. 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.