Raspberrypi-vc Packaging 0.1 (2nd entry)

Building the package in the arm machine.

I got my Pi up and running and downloaded the spec file I used for my Pi. The BuildArch was set to armv6hl but everything is still the same. The build was successful and wrote 2 rpms. The build time was relatively slow compared to PC, of course, but it was successful.

I tried installing the rpm using $rpm -i raspberrypi-vc-debuginfo-0.1-5.rpm and got no output. No output means good output, usually in Linux. As I have told. 

For the next entry and my 0.1 release, I will finish my spec file properly and try out adding a %build section and the %install section. Also, will try to send for review.

Next entry goals (0.1 3rd entry):

• Updated (clean) spec file.
• Try to put something in %build and %install section.
• Investigate the %install section from src rpm spec file.
• 0.1 Release

Raspberrypi-vc Packaging 0.1 (1st entry)

The project I chose is packaging the raspberrypi-vc package to build from source. Here are the links necessary regarding the information about this project (includes project planning).

I started by obtaining the source rpm. The spec file was long and very complicated to understand to my level. In reviewing the specfile, I noticed a bunch of subpackages that are also being built along the process. This files are libraries and development tools. Here's how it is laid out:

each %package tag  will build a sub package. Each subpackage needed a directory containing the files necessary for the building process:

 

each %file needs the name of the subpackage that will be built.

The goal of the project is to make an rpm which was built from. I created a new spec file just like I did in the labs. I did it with the simplest form and with no macros just to test it out if it could work. *Note, I am using my pc to build the rpm (raspberrypi-vc is intented for arm architectures).

I copied the tags from the src specfile but I manually input the source. Just for testing purposes.

After doing $rpmbuild -ba, I got an error : make: *** No targets specified and no makefile found.  Stop.
error: Bad exit status from /var/tmp/rpm-tmp.jDPPf5 (%build)

It means that there are no files that the command $make could identify in the %build section (make %{?_smp_mflags}). In the original spec file, the commands for %build section was not present. Thus I removed the make and the spec file was built successfully without errors.

 Wrote: /home/jfgiagonia/rpmbuild/RPMS/x86_64/raspberrypi-vc-debuginfo-0.1-5.rpfr19.x86_64.rpm

The build from source was successful but with everything strip down. The % build and %install section was empty and there are no changelogs. The next step is try to build it on Pi.

Sources:

SBR600 Project Page -> Look for 'Change Raspberrypi-package...'

Project Planning

Source RPM

Tarball Original Source

Python Lab

Scripting is my very least skill in computers. I found bash to be very difficult to learn but I have somewhat knowledge about it. Comparing to python, I would say this is easier and faster to learn. Although, this is still a challenge for me.

I looked at some of the blog posts to help me understand the 'guess' script and I found amartinenco's script to be the most understandable. So I tried to modifying my script and trying it on my own and this is what I came up:

#!/usr/bin/python
#
# Modify this script to be a number-guessing
# game.
# 1. The secret number should be random (1-100)
# 2. Input should be handled if it's not numeric
# 3. The user should be asked to guess until they
#    get the right number.
# 4. When the user guesses the right number, the
#    number of guesses should be printed
#
# Bonus: Make the script give up if the number hasn't
#        been guessed in 15 tries.

# imports sys program to script
import sys
# imports random program to the sript
import random
secret=random.randint(1,100)



game_finished = 0
count = 1
print "Guess the number from 1-100. You have 15 tries"

while (game_finished == 0):
  try:
     guess=int(raw_input("Enter a guess: "))

     if guess < 1 or guess > 100:
        print "Must be in the (1-100) range"
     else:
        if guess < secret:
           count = count + 1
       print "Too low!"        
        elif guess > secret:
           count = count + 1
       print "Too high!"        
        else:
           print "Correct!"
           game_finished = 1
           print "It took you %i tries to guess the correct number" % (int(count))
     if count == 16:
       print "number of tries exceeded(15). exiting"
       sys.exit()
  except ValueError:
     print "The entered input is invalid"

The only difference from where the script I got from was the exit script when the tries have been exceeded. Python is easier and more exciting to learn compared to other scripts I have learned. As for the future, I would try to have an in depth look at this language as this would be a great skill for the future.

End.

SBR600 Project

Greetings!

I have checked the package, raspberrypi-vc package from the koji site and I am lost. This would be a challenge as i do not know which package I need to work on and how to start it. This post is a call for help if you may know what is the first thing I should do.

The objective of my project is to make the raspberrypi-vc package build from source. The expected result is a raspberrypi-vc package that will be built from source, and will be compatible with the current Pidora packaging.

Challenges:
1. Know the purpose of the package.
2. how to obtain the the package.

Mock and Koji Lab

Mock and Koji Lab

MOCK LAB

PREPARATION

Installed mock using yum install.
Added my username to the group.
All commands with sudo
Using time, i recorded the time it finished the mock.

















Everything went smooth,no errors( no known errors ), I was curious as to put anything on the Buildrequires and Requires tags are for. I left it commented for now and see if any errors rise. Tried testing rpmbuild again to see the difference and used rpmlint to check the package which mock built. compared to rpmbuild, mock, I think, is slower maybe because it uses internet connection and that it can affect the speed.

*Note, i have fixed an issue where I put directories on the %files of the spec file. I changed the directories to macros in order for it to be dynamic.




 

KOJI LAB

PREPARATION

The fedora-packager-setup was already installed
used this command to interface with the koji server
$/usr/bin/fedora-packager-setup

*It asked for my FAS user and password.

Next step is I imported the certificates to use the interface using firefox.

QUEUEING the build request

First, we do the command:
$ koji build f18 --scratch units-2.02-1.fc17.src.rpm

*I was hoping there are no errors and it did not have any. Made me happy! The command will build the package using the koji server for x86_34, i386, and i686 architectures

The link of the task is here:

the architectures are built for
    buildArch (units-2.02-1.fc17.src.rpm, x86_64)
    buildArch (units-2.02-1.fc17.src.rpm, i686)

It is very rewarding to see my name on the list of recent tasks. feels good to be a part of this project. (=

Now trying to build rpms for these architectures:

1.) s390
$ s390-koji build f18 --scratch units-2.02-1.fc17.src.rpm
The build had no errors, this is the link to the build.


2.) power pc (PPC)
$ ppc-koji build f18 --scratch units-2.02-1.fc17.src.rpm
Here's the link.


3.) armv6hl / Pidora
$ arm-koji build f18 --scratch units-2.02-1.fc17.src.rpm
Arm build has failed with these errors. mostly jibberish for me.











Will try to ask for help on the chat and classroom in order to make a build for arm. This is very important as the project I will be doing is for the arm architecture.


REFLECTIONS

I can say that this lab is very rewarding. I am the kind of person who intends to lean on the negative and for this lab I was sure to get a lot of errors. But to my surprise, I got none. The koji lab is very interesting. It really gave me the experience of being inlcuded in the fedora community and to see my name on the Recent Tasks page is an accomplishment.
This lab will be very useful for the upcoming project I will do for the Pidora because it will include packaging skills and mock and koji.

RPM packaging Process

Preparation

First and foremost, I installed the required packages: Fedora Packager (group of packages) and rpmlint and yum-utils

$ sudo yum -y groupinstall "Fedora Packager"

Next Package

$ sudo yum -y install rpmlint yum-utils


After installing the packages I created the ~/rpmbuild directories and the ~/.rpmmacros file through this command:

$ rpmdev-setuptree

I made sure that these directories and file are created. Here are the screenshots:










RPM-writing Steps:

1) From the previous packages on build-from-source blog, I get the two packages I chose and moved it to ~/rpmbuild/SOURCES directory. The packages should be in tarball.

$ mv Downloads/units-2.02.tar.gz rpmbuild/SOURCES/
$ mv Downloads/radius-1.6.1.tar.gz rpmbuild/SOURCES/

2) Change directory to ~/rpmbuild/SOURCES

$ cd ~/rpmbuild/SOURCES

3) From this directory, I created an empty spec file for the packages

$ rpmdev-newspec units-2.02.tar.gz 
$ rpmdev-newspec radius-1.6.1.tar.gz

4) Using vi, I edited the specfile and fill in the corresponding metadata.
After my first try, I received this errors.

Name:           units-2.02.tar.gz
Version:        2.02
Release:        1%{?dist}
Summary:        Converting units from one to another

License:        GPLv3
URL:            http://www.gnu.org/software/units
Source0:        http://ftp.gnu.org/gnu/units/units-2.02.tar.gz

#BuildRequires: 
#Requires:      



$ rpmbuild -ba units-2.02.tar.gz.spec
error: File /home/jfgiagonia/rpmbuild/SOURCES is smaller than 13 bytes
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.NXTyCn
+ umask 022
+ cd /home/jfgiagonia/rpmbuild/BUILD
+ LANG=C
+ export LANG
+ unset DISPLAY
+ cd /home/jfgiagonia/rpmbuild/BUILD
+ rm -rf units-2.02.tar.gz-2.02
+ /usr/bin/tar -xf /home/jfgiagonia/rpmbuild/SOURCES
/usr/bin/tar: /home/jfgiagonia/rpmbuild/SOURCES: Cannot read: Is a directory
/usr/bin/tar: At beginning of tape, quitting now
/usr/bin/tar: Error is not recoverable: exiting now
error: Bad exit status from /var/tmp/rpm-tmp.NXTyCn (%prep)


RPM build errors:
    File /home/jfgiagonia/rpmbuild/SOURCES is smaller than 13 bytes
    Bad exit status from /var/tmp/rpm-tmp.NXTyCn (%prep)

Solution: removed the forward slashes from both source and URL. solution found on this forum. http://www.redhat.com/archives/fedora-packaging/2009-December/msg00020.html

After the fix, a new error came.

$ rpmbuild -ba units-2.02.tar.gz.spec
error: File /home/jfgiagonia/rpmbuild/SOURCES/units: No such file or directory

Solution: Change Source0 to: http://ftp.gnu.org/gnu/units/units-2.02.tar.gz

New error: Bad exit status from /var/tmp/rpm-tmp.nADFQG (%prep)

Solution: Change the name to just units

New errors:    
Installed (but unpackaged) file(s) found:
   /usr/bin/units
   /usr/bin/units_cur
   /usr/share/info/units.info.gz
   /usr/share/man/man1/units.1.gz
   /usr/share/units/currency.units
   /usr/share/units/definitions.units
   /usr/share/units/locale.map

Solution: Added the files onto the %files section. Found the solution on Jason Carman's blog.

After the last solution, the build was successful. the rpms were successfully placed on /rpmbuild/RPMS/x86_64/ and /rpmbuild/SRPMS/

TESTING THE BUILD:

Using the rpmlint -i command, I received a lot of errors. Some errors were about the changelog, %post and %postun entries (scriptlets), and invalid urls. Most of the solution were found in the blogs of my classmates. After fixing the errors all that is left were the warnings for the specfile and the two rpms. The Radius package was also successfully built and the process and the solutions were the same as the Units package.

Build-From-Source Lab

The first step of this lab was to install Development Tools and Development Libraries using yum.

$ yum groupinstall "Develeopment Tools" "Development Libraries"

I chose two packages that I can test at this site. I downloaded Units(converts certain units to other units)  and Radius (remote user authentication and accounting) both in.tar extensions. used tar to unzip.

On to building from the source
Steps:

Download the packages and the extract. Both files were in .tar.gz format so I used tar to extract.

$ tar xvzf units-2.02.tar.gz

Next was to run the configure script to find any compatibility issues on a wide variety of computers. we time it to know how long it takes it to execute

$ time ./configure

real    0m1.328s
user    0m0.619s
sys    0m0.329s


Now in order to build the software, we use the command make. Again we time.

$ time make

real    0m0.224s
user    0m0.103s
sys    0m0.054s

After running the command there was no known errors that has shown which means that it run successfully. A way to really check if it is issue-free was for make-install but it was not recommended as it will overwrite files to the system.

Thanks to jmcarman from #seneca channel for helping.