Saturday, December 21, 2013

Raspberrypi-userland

 Building a new package called raspberrypi-userland package. The files are located in this site.

RPM BUILDING

With the help of Adam Pensrose's spec file I mange to create a spec file with global commands. The build was successful and there were no errors encountered.

RPM LINT

Using rpmlint command, I checked for errors and found a couple. I fixed them and did the packaging process again.

ARCH

The architecture that I am building it on is on f17, for my next blog I will build the package in the arm architecture (Pi).

Files and Links
Spec file
Source RPM (tar.gz)








Sunday, December 15, 2013

Raspberrypi-vc Packaging (Final Release)

Changing the package 'raspberrypi-vc' to build from source is very complicated (for me). As I reach the deadline, here's what I tried to accomplish and the challenges I faced:

1.) I always look the original spec file from agreene and I would say, at first I did not understand most of what was there. Because of that, I did not know how to start my project (I thought it was a simple 'kind-of-a-lab' project but it isn't) which is a problem. I did talk with Chris and told me to start off from scratch and so I did but then I got stuck.

2.) As I build the package from a skeleton spec with everything almost empty, I looked everywhere for a make file or anything with a script (python mostly) just to be able to build it but there was none. I looked at almost all of the packages in the project and everything includes a make file or something to put in the %build section and it makes it really easier. As for mine, I found none for raspberrypi-vc package except when I looked inside the hello_pi directory(I found the rebuild.sh, a python script). It shed some light but I faced another challenge.

3.)  I edited the spec file to include the rebuild.sh and I got errors that says some files where missing. I addressed the issue by editing the makefile through the specfile and adding the specific directory on where to find it (I put this in %build section sed -i -e '1iSDKSTAGE=/home/jfgiagonia/rpmbuild/BUILD/raspberrypi-firmware-4c14569/hardfp\' Makefile.include). The file could not be found issue is fixed but again another issue came up.

4.)  The next issue that came up, and probably the one thing holding me is:
/usr/bin/ld: skipping incompatible /home/jfgiagonia/rpmbuild/BUILD/raspberrypi-firmware-4c14569/hardfp/opt/vc/lib//libGLESv2.so when searching for -lGLESv2
/usr/bin/ld: cannot find -lGLESv2
/usr/bin/ld: skipping incompatible /home/jfgiagonia/rpmbuild/BUILD/raspberrypi-firmware-4c14569/hardfp/opt/vc/lib//libEGL.so when searching for -lEGL
/usr/bin/ld: cannot find -lEGL
/usr/bin/ld: skipping incompatible /home/jfgiagonia/rpmbuild/BUILD/raspberrypi-firmware-4c14569/hardfp/opt/vc/lib//libopenmaxil.so when searching for -lopenmaxil
/usr/bin/ld: cannot find -lopenmaxil
/usr/bin/ld: skipping incompatible /home/jfgiagonia/rpmbuild/BUILD/raspberrypi-firmware-4c14569/hardfp/opt/vc/lib//libbcm_host.so when searching for -lbcm_host
/usr/bin/ld: cannot find -lbcm_host
/usr/bin/ld: skipping incompatible /home/jfgiagonia/rpmbuild/BUILD/raspberrypi-firmware-4c14569/hardfp/opt/vc/lib//libvcos.so when searching for -lvcos
/usr/bin/ld: cannot find -lvcos
/usr/bin/ld: skipping incompatible /home/jfgiagonia/rpmbuild/BUILD/raspberrypi-firmware-4c14569/hardfp/opt/vc/lib//libvchiq_arm.so when searching for -lvchiq_arm
/usr/bin/ld: cannot find -lvchiq_arm
collect2: error: ld returned 1 exit status
make: *** [hello_teapot.bin] Error 1
rm models.o video.o triangle.o
make: Leaving directory `/home/jfgiagonia/rpmbuild/BUILD/raspberrypi-firmware-4c14569/hardfp/opt/vc/src/hello_pi/hello_teapot'
error: Bad exit status from /var/tmp/rpm-tmp.zjVMmP (%build)

This goes on to every file that the make file compiles.

5.) Building from source on the Pi is very slow that's why most of my building was done on a PC. Maybe my sd card was not fast enough but that being said, I tried it on Pi and still, it does not build properly.

Thoughts:
Overall I would still say that building packages is very interesting. It gives you quite a skill to look for errors and find solutions. It is like a job of a QA Analyst so that the software does not or have less bugs. Also, talking to other people in the community for help is one thing you can develop on this project. I could have talked to more people and I might have found solutions to this but I got caught up with other projects and practicals (my fault anyway). The project has taught me to prioritize and plan things carefully in order to not be caught by the deadlines. It is a very important skill not only in school but also on other places like work. As I end, everything what I have done in this course is worth it. From the communications lab (and every lab) until the project. Chris is a very good teacher and I would recommend IT students to get him as your instructor in any subject he is teaching.

Files:
Source RPM
Spec File
(I copied the header information from the original spec file)

Links:
My Project
Github Source Files

Saturday, December 14, 2013

Raspberrypi-vc Packaging

As I go back on finding the errors from my previous blog, I found out what was causing it. The Makefile.include did not provide any directory on where to point out the necessary files so fixed it by adding a manual entry on the specfile to have it point to the appropriate directory.

%build
cd hardfp/opt/vc/src/hello_pi
sed -i -e '1iSDKSTAGE=/home/jfgiagonia/rpmbuild/BUILD/raspberrypi-firmware-4c14569/hardfp\' Makefile.include
./rebuild.sh


And then when I tried to do rpmbuild -ba I got new errors that I could not figure out yet what's causing it.

Error:
jpeg.c:361:171: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
cc -o hello_jpeg.bin -Wl,--whole-archive jpeg.o -lilclient -L/home/jfgiagonia/rpmbuild/BUILD/raspberrypi-firmware-4c14569/hardfp/opt/vc/lib/ -lGLESv2 -lEGL -lopenmaxil -lbcm_host -lvcos -lvchiq_arm -lpthread -lrt -L../libs/ilclient -L../libs/vgfont -Wl,--no-whole-archive -rdynamic
/usr/bin/ld: skipping incompatible /home/jfgiagonia/rpmbuild/BUILD/raspberrypi-firmware-4c14569/hardfp/opt/vc/lib//libGLESv2.so when searching for -lGLESv2
/usr/bin/ld: cannot find -lGLESv2
/usr/bin/ld: skipping incompatible /home/jfgiagonia/rpmbuild/BUILD/raspberrypi-firmware-4c14569/hardfp/opt/vc/lib//libEGL.so when searching for -lEGL
/usr/bin/ld: cannot find -lEGL
/usr/bin/ld: skipping incompatible /home/jfgiagonia/rpmbuild/BUILD/raspberrypi-firmware-4c14569/hardfp/opt/vc/lib//libopenmaxil.so when searching for -lopenmaxil
/usr/bin/ld: cannot find -lopenmaxil
/usr/bin/ld: skipping incompatible /home/jfgiagonia/rpmbuild/BUILD/raspberrypi-firmware-4c14569/hardfp/opt/vc/lib//libbcm_host.so when searching for -lbcm_host
/usr/bin/ld: cannot find -lbcm_host
/usr/bin/ld: skipping incompatible /home/jfgiagonia/rpmbuild/BUILD/raspberrypi-firmware-4c14569/hardfp/opt/vc/lib//libvcos.so when searching for -lvcos
/usr/bin/ld: cannot find -lvcos
/usr/bin/ld: skipping incompatible /home/jfgiagonia/rpmbuild/BUILD/raspberrypi-firmware-4c14569/hardfp/opt/vc/lib//libvchiq_arm.so when searching for -lvchiq_arm
/usr/bin/ld: cannot find -lvchiq_arm
collect2: error: ld returned 1 exit status
make: *** [hello_jpeg.bin] Error 1





Searching for further fixes until next post.

PS. I may not able to finish this project up to release 0.3. The packaging process is very complicated and I have never touched the makefiles before.


Wednesday, December 4, 2013

Raspberrypi-vc Packaging 0.1 (3nd entry)

Building the raspberrypi-vc from source was harder than I thought. The spec file I got from the source RPM was setup in a very complicated way ( for me ) but I understood it in a way. I found a makefile in the hello_pi folder and tried to work it from there and see if it would build it from source.

These lines were added to the %build section:

cd hardfp/opt/vc/src/hello_pi/
make -C libs/ilclient
make -C libs/vgfont
./rebuild.sh


OUTPUT:

[jfgiagonia@f17 SPECS]$ rpmbuild -ba raspberrypi-vc.spec
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.td65cK
+ umask 022
+ cd /home/jfgiagonia/rpmbuild/BUILD
+ LANG=C
+ export LANG
+ unset DISPLAY
+ cd /home/jfgiagonia/rpmbuild/BUILD
+ rm -rf raspberrypi-firmware-4c14569
+ /usr/bin/gzip -dc /home/jfgiagonia/rpmbuild/SOURCES/4c1456944b5f6cc9e5141077ed4e158398811fc1
+ /usr/bin/tar -xf -
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ cd raspberrypi-firmware-4c14569
+ /usr/bin/chmod -Rf a+rX,u+w,g-w,o-w .
+ exit 0
Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.Qx5RP8
+ umask 022
+ cd /home/jfgiagonia/rpmbuild/BUILD
+ cd raspberrypi-firmware-4c14569
+ LANG=C
+ export LANG
+ unset DISPLAY
+ cd hardfp/opt/vc/src/hello_pi/
+ make -C libs/ilclient
make: Entering directory `/home/jfgiagonia/rpmbuild/BUILD/raspberrypi-firmware-4c14569/hardfp/opt/vc/src/hello_pi/libs/ilclient'
cc -DSTANDALONE -D__STDC_CONSTANT_MACROS -D__STDC_LIMIT_MACROS -DTARGET_POSIX -D_LINUX -fPIC -DPIC -D_REENTRANT -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -U_FORTIFY_SOURCE -Wall -g -DHAVE_LIBOPENMAX=2 -DOMX -DOMX_SKIP64BIT -ftree-vectorize -pipe -DUSE_EXTERNAL_OMX -DHAVE_LIBBCM_HOST -DUSE_EXTERNAL_LIBBCM_HOST -DUSE_VCHIQ_ARM -Wno-psabi -I/opt/vc/include/ -I/opt/vc/include/interface/vcos/pthreads -I/opt/vc/include/interface/vmcs_host/linux -I./ -I../libs/ilclient -I../libs/vgfont -g -c ilclient.c -o ilclient.o -Wno-deprecated-declarations
ilclient.c:50:33: fatal error: interface/vcos/vcos.h: No such file or directory
compilation terminated.
make: *** [ilclient.o] Error 1
make: Leaving directory `/home/jfgiagonia/rpmbuild/BUILD/raspberrypi-firmware-4c14569/hardfp/opt/vc/src/hello_pi/libs/ilclient'
error: Bad exit status from /var/tmp/rpm-tmp.Qx5RP8 (%build)


RPM build errors:
    Bad exit status from /var/tmp/rpm-tmp.Qx5RP8 (%build)

Good news was at least there was make file that would actually run. The error 'interface/vcos/vcos.h: No such file or directory was because the ilcient.c file needed it to proceed with make. The problem is this file can only be gotten from raspberrypi/userland on github and it is itself, another source code different from what i am working on. I will be working to see if there is a way on my next entry.

PS. This is a very difficult packaging process from the normal packages I tried before. Tinkering with the make files and scripts are not my best assets but I will try the best I can to accomplish a build from source package.

Tuesday, November 19, 2013

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

Monday, November 18, 2013

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...'










Friday, November 8, 2013

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.


Wednesday, November 6, 2013

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.

Tuesday, October 1, 2013

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.





Sunday, September 22, 2013

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.









Wednesday, September 18, 2013

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.

Pilot: My First Blog


This is my first time ever to blog and I think it's quite cool.

    I enrolled at SBR600 to know more about open source and open source projects. I am quite fascinated by how open source operates. Programming and coding are the weakest skills I have but I know to myself that I need to learn this and this is a very useful skill as an IT.

    Contact me through:

IRC nick: TheDib
LearnID: jfgiagonia
IRC snippet:















The Raspberry Pidora project interests me. To be able to make cheap programmable computers for use is amazing. Who knows we might be able make computers very affordable and portable at the same time and not having the profit as the main drive. I think this is a great innovation by the developers and I hope in some way I could contribute to this project. It would be very rewarding to know that somehow you were part of a project that changed a part of the world.