Key cutting
The first portion of this weeks lab was simple and did not pose any difficulty; we had to complete these three tasks.
- Create gpg certificates
- Sign your RPM packages
- Create the ASCII public key file
Not having rpm-sign or gnupg installed, I yum installed them. They did not have any dependancies associated with them (at least dependancies I didn’t already have installed).
I entered the command gpg --gen-key and answered the questions as I was prompted (for email, passphrase, etc). The key generation required random processes to happen. I ran the top command along with several packet internet gropers along with web browsing. I was periodically prompted with the armound of bytes needed to complete the task, which incremented faster as I started more processes.
I edited the /home/shkim33/.rpmmacros file and appending my email address to the bottom of the file, beginning with %_gpg_name.
Below is the process of signing both the packages I have been working with thus far (bc and which):
rpm --addsign which-2.20-6.fc19.x86_64.rpm
Enter pass phrase:
Pass phrase is good.
which-2.20-6.fc19.x86_64.rpm:
rpm --addsign bc-1.06.95-10.fc19.x86_64.rpm
Enter pass phrase:
Pass phrase is good.
bc-1.06.95-10.fc19.x86_64.rpm:
The final task of generating an ASCII public key file was rather simple.
麹
I decided to run my “which” rpm through the koji system. I had a small hic-up while configuring my computer to use Koji, and still having issues logging into my FAS account through the web browser. I will have to troubleshoot the issue downt the road. If anyone out there has any suggestions, here is the error message I am getting when I click on “login” while at the koji site.
Secure Connection Failed
An error occurred during a connection to koji.fedoraproject.org. SSL peer was unable to negotiate an acceptable set of security parameters. (Error code: ssl_error_handshake_failure_alert)
The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
Please contact the website owners to inform them of this problem. Alternatively, use the command found in the help menu to report this broken site.
I believe I loaded the proper cert into the browser, and even did it mutliple times to ensure I followed the steps provided here. All suggestions are welcome.
Even with the issues above, I was able to continue with the koji lab. I first ran it through the standard intel/amd architectures with no issues. The run time was as below (using the time command prefix):
real 2m47.528s
user 0m1.215s
sys 0m0.238s
I also has no issues running it through s390, not receiving errors. Total run time below (using the time command prefix):
real 5m40.999s
user 0m2.490s
sys 0m0.268s
Lastly, I ran the source rpm through the power pc architecture, also with no errors. Total run time below (using the time command prefix):
real 4m20.501s
user 0m1.898s
sys 0m0.245s
Which being a simple program I did not really expect to run into any errors. I will have to attempt the same with a more complex RPM in the future just to see if I can get some interesting output. Below are quick links to the koji pages for each build.
Koji is a very interesting tool, which I believe, embodies the idea of the fedora, and other open source, communities. I can see a list of members and what packages they have been testing.
Mock’ing
Before starting the mock lab, I realized something concerning the previous lab. When building the .RPM for bc, I encountered an error where a dependacy was required (texinfo). Because of this, I added texinfo to BuildRequires. Prior to that lab, while building from source, I had to install a dependacy and had to yum install flex.x86_64. I did not take this into account while writing the spec file; however the rpmbuild and rpmlint occured without any errors. I suspect that I will receive an error requiring this missing dependency.
After setting lup the mock environment, and adding my user account to the mock group, I spent the next few seconds trying to find the log out button on fedora 19. Apparently there is no log out selection. I can turn off the machine, reboot it, lock it and even suspend it, but I cannot log off to the log in screen. I had to accomplish this through the CLI (oh what would we do without CLI). For those wondering, the command is gnome-session-quit.
I started with which.
mock -r fedora-19-x86_64 ~/lab2/which/which-2.20-6.fc19.src.rpm
The entire process took 9 minutes and 50 seconds, but it completed without any issue. The command was nice enough to let me know the results could be found in /var/lib/mock/fedora-19-x86_64/result.
A small excerpt to denoting success!
Checking for unpackaged file(s): /usr/lib/rpm/check-files /builddir/build/BUILDROOT/which-2.20-6.fc19.x86_64
Wrote: /builddir/build/RPMS/which-2.20-6.fc19.x86_64.rpm
Wrote: /builddir/build/RPMS/which-debuginfo-2.20-6.fc19.x86_64.rpm
Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.dH0QZh
+ umask 022
+ cd /builddir/build/BUILD
+ cd which-2.20
+ /usr/bin/rm -rf /builddir/build/BUILDROOT/which-2.20-6.fc19.x86_64
+ exit 0
Child return code was: 0
LEAVE do -->
Since this was a success, I moved onto my next package, bc. This time, the mock took only 43 seconds. But this was not the surprising part of it. I was expecting this to fail since it was built without flex being stated for BuildRequires. However, it seems to have completed successfully.
Checking for unpackaged file(s): /usr/lib/rpm/check-files /builddir/build/BUILDROOT/bc-1.06.95-10.fc19.x86_64
Wrote: /builddir/build/RPMS/bc-1.06.95-10.fc19.x86_64.rpm
Wrote: /builddir/build/RPMS/bc-debuginfo-1.06.95-10.fc19.x86_64.rpm
Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.PC4w8D
+ umask 022
+ cd /builddir/build/BUILD
+ cd bc-1.06.95
+ /usr/bin/rm -rf /builddir/build/BUILDROOT/bc-1.06.95-10.fc19.x86_64
+ exit 0
Child return code was: 0
LEAVE do -->
I will have to look into why this completed successfully without requiring flex. But first I will move onto the Koji lab, as that may provide some insight.
Build an RPM for the first time | bc > lesson in frustration
While the previous labs went smoothly, I spent a good portion of my weekend working on building these RPMs. My main issue was not understanding what error messages meant, and having to track down the solution to the issue. After completing the rpm build set up (which I will not go into, since those steps are outline in the lab), I will begin with the first package I built, bc.
Once there was a blank spec file in the appropriate directory, I decided to simply run rpmbuild -ba bc.spec to find out what would happen. I received the following error:
error: line 2: Empty tag: Version:
Obviously I needed to fill in some of the fields.
Name: bc
Version: 1.06.95
Release: 10%{?dist}
Summary: A calculator
License: GPLv2+
URL: http://www.gnu.org/software/bc/
Source0: ftp://alpha.gnu.org/pub/gnu/bc/bc-%{version}.tar.bz2
-ba’ing it again, I receive:
/bin/sh: line 9: makeinfo: command not found
/bin/sh: line 9: makeinfo: command not found
Doing some research, it seems a package is required to run the makeinfo command. To install the necessary package, I ran: yum install texinfo.x86_64. There isn’t much information out there stating that this is the package required for the makeinfo command, so some digging was required. Since, I need to install texinfo to perform the build, I added texinfo to the .spec file under BuildRequires.
-ba’ing it again!, I received:
error: Installed (but unpackaged) file(s) found:
/usr/bin/bc
/usr/bin/dc
/usr/share/info/bc.info.gz
/usr/share/info/dc.info.gz
/usr/share/info/dir
/usr/share/man/man1/bc.1.gz
/usr/share/man/man1/dc.1.gz
RPM build errors:
Installed (but unpackaged) file(s) found:
/usr/bin/bc
/usr/bin/dc
/usr/share/info/bc.info.gz
/usr/share/info/dc.info.gz
/usr/share/info/dir
/usr/share/man/man1/bc.1.gz
/usr/share/man/man1/dc.1.gz
At first I simply cut and pasted these lines under the %files tag, but then remembered Chris Tylers recommendation on using macros, so I ended up adding the following lines:
%{_bindir}/bc
%{_bindir}/dc
%{_infodir}/*
%{_mandir}/*/*
-ba’ing once again, the build completed with exit code 0 (or SUCCESS!). Now onto the lint tests. I did not run into any serious errors (disregarding changelog errors for now) until I tested the binary. Below is the output of rpmlint for .spec, src and the binary:
spec:
0 packages and 1 specfiles checked; 0 errors, 0 warnings.
src:
bc.src: E: no-changelogname-tag
1 packages and 0 specfiles checked; 1 errors, 0 warnings.
rpm:
bc.x86_64: E: no-changelogname-tag
bc.x86_64: E: info-dir-file /usr/share/info/dir
1 packages and 0 specfiles checked; 2 errors, 0 warnings.
To get more information on the bc.x86_64: E: info-dir-file /usr/share/info/dir error, I ran rpmlint with the -i trigger. The resulting message was thus:
bc.x86_64: E: info-dir-file /usr/share/info/dir
You have /usr/info/dir or /usr/share/info/dir in your package. It will cause
conflicts with other packages and thus is not allowed. Please remove it and
rebuild your package.
After some more research and reading the -i error message word for word, I realized that lint was requesting to delete that directory. Referencing blog posts from previous SBR600 students, I found that I needed to add rm -f $RPM_BUILD_ROOT/%{_infodir}/dir after %make_install. After this was added, the rpmlint roller went over spec file and the three RPMs with only the change log error. Upon adding an entry into the change log section and -ba’ing it again, I received the following for each lint test:
[shkim33@zeus SPECS]$ rpmlint bc.spec
0 packages and 1 specfiles checked; 0 errors, 0 warnings.
[shkim33@zeus SPECS]$ rpmlint /home/shkim33/rpmbuild/SRPMS/bc-1.06.95-10.fc19.src.rpm
1 packages and 0 specfiles checked; 0 errors, 0 warnings.
[shkim33@zeus SPECS]$ rpmlint /home/shkim33/rpmbuild/RPMS/x86_64/bc-1.06.95-10.fc19.x86_64.rpm
1 packages and 0 specfiles checked; 0 errors, 0 warnings.
[shkim33@zeus SPECS]$ rpmlint /home/shkim33/rpmbuild/RPMS/x86_64/bc-debuginfo-1.06.95-10.fc19.x86_64.rpm
1 packages and 0 specfiles checked; 0 errors, 0 warnings.
My second package was which. The process for building this pretty much went the same as the building process for bc. However, I ran into an error that I spent several hours on trying to correct.
which-debuginfo.x86_64: E: incorrect-fsf-address /usr/src/debug/which-2.20/getopt.h
which-debuginfo.x86_64: E: incorrect-fsf-address /usr/src/debug/which-2.20/tilde/xmalloc.h
which-debuginfo.x86_64: E: incorrect-fsf-address /usr/src/debug/which-2.20/tilde/tilde.c
which-debuginfo.x86_64: E: incorrect-fsf-address /usr/src/debug/which-2.20/bash.c
which-debuginfo.x86_64: E: incorrect-fsf-address /usr/src/debug/which-2.20/tilde/tilde.h
The second hit on google pointed to the fedoraproject where this error was on the Common Rpmlint issues. After speaking with the professor over IIRC, he provided a YouTube video link on how to fix the issue, but also stated that I should treat it as a warning. Wanting to remove the error from the list, I attempted to follow the instructions verbatim, however, I could not find the files in the locations specified. Speaking with the professor in class, it seems that the file with the errors in located elsewhere until another name. I will leave it for now, but I plan on revisiting the issue to get some hands on experience on doing it.
Links to the files are below:
WHICH:
which.spec
which-2.20-6.fc19.src.rpm
which-2.20-6.fc19.x86_64.rpm
which-debuginfo-2.20-6.fc19.x86_64.rpm
BC:
bc.spec
bc-1.06.95-10.fc19.src.rpm
bc-1.06.95-10.fc19.x86_64.rpm
which-debuginfo-2.20-6.fc19.x86_64.rpm
Which Hunt
For our second week in SBR600, we were required to take two packages from the GNU Software Collection and build them. The two I chose were which and bc. The first, which, installed without much issue. The configure command, for which, took: real=0m3.331s; user=0m1.009s; and sys=0m0.672s. The make command took: real=0m0.657s; user=0m0.508s; and sys=0m0.101s
The second package chosen, bc, encoutered a small problem. Upon giving the ./configure command, I received the following:
checking lex output file root... ./configure: line 1274: lex: command not found
configure: error: cannot find output from lex; giving up
After a quick investigation, it seemed I needed to install a program called flex.x86_64, a tool for creating scanners (text pattern recognizers). This was done with the command yum install flex.x86_64. After the installation the ./configure command executed successfully in: real=0m2.328s; user=0m0.792s; and sys=0m0.323s. The make command did not encounter any issues, taking: real=0m2.425s; user=0m2.103s; and sys=0m0.270s.
Testing was simple for both. The command ./which which resulted in /bin/which, and ./which ifconfig resulted in /sbin/ifconfig The results for bc are the following:
echo "20 + 22" | bc results in 42
echo "7 * 6" | bc results in 42
echo "378 / 9" | bc results in 42
echo "2468 - 2426" | bc results in 42
echo "the answer to life the universe and everything" | bc results in 42
Well the last test might not be true, but it should be!
These are the links to the built software!
Download WHICH
Download BC
-Ricahrd K.
What would you RISC?
HELP! I accidentally built a shelf!
My name is Sung Hwan Richard Kim. I am currently a 5th semester CTY student @ Seneca College. The reason you are reading this is because not because I accidentally built a shelf (not sure how that is even possible), but because I am enrolled in this semesters SBR600. I am sure many of you have become accustomed to the spam around this time of the year when students are FORCED encouraged to make their first steps into the open community; so my addition to your daily spam information intake will go unnoticed.
I am returning to school from a 4 month co-op term with SOCAN. Previous to my position there, I have served 4 month co-op terms with MPAC and NexJ Systems. You can find some more information about myself here; which I will be adding more content to in the future…hopefully.
My IRC handle is professorplum, and while I was in channel I was able to catch our Glorious Leader, Chris Tyler, speaking to the masses.
[ctyler] adpaolucci: we're getting the new open source students on the blogs. There's a lot of similarity in the first posts within each class :-S
[adpaolucci] I'm surprised to only see WordPress and no jekyll
* elnushaj has quit (Ping timeout: 245 seconds)
[dimon222] ]jekyll
[dimon222] makes no sense at least for me
[dimon222] is it engine?
* dimon222 has quit (Read error: Connection reset by peer)
[adpaolucci] Python based site generator
[adpaolucci] Python based site generator
[dimon222] hoh
[dimon222] sounds like the hard way
[adpaolucci] Github blogs are based on it
[dimon222] whats the idea of using python based generators instead of specialized blog engines?
[dimon222] going in a hard way
[adpaolucci] You have more indepth control with jekyll
[adpaolucci] and better performance
[dimon222] yeah, but its not just a blog anymore
[adpaolucci] Students could even host it on their matrix accounts
[dimon222] cant really agree about better performance
[dimon222] not sure really, but..
[adpaolucci] static html vs php engine
[dimon222] oh
[adpaolucci] the python script compiles it all into .html files
[dimon222] well, thats sounds different from what I thought
[dimon222] alright then
[ctyler] They're welcome to setup whatever they want; most take the shortest path of blogger.com or wordpress.com -- both are reasonable for this purpose.
Perhaps I will have to take a look at this jekyll
My LearnID is shkim33; which possibly means there were 33 other people with shkim (shkim + shkim[1-32]) prior to me!.
Pidora looks interesting and I believe it could be the first steps into something much bigger. With computing shifting to more mobile technologies, we may be interested in being able to install and run our choice of operating systems on those devices. On our PCs, we are free to install whatever operating system we wish: the different versions of Windows; and the different distributions of Linux (including OSX). But on our mobile devices, such as tablets and phones, we are far more limited, generally to the operating system packaged by the manufacturer of the device ( with a few exceptions of people rooting their devices ).
Being able to package Fedora for a specific set of hardware and allowing the overall size of it to be much smaller, we could see it being customized for phones and tablets; which means we may see integration between devices. Microsoft seems to be on a similar train of thought; integrating several different technologies with a customized version of their Windows Operating System. Xbox One runs a customized version of Windows, while Windows Phone 8 uses the Windows NT Kernel. I would be a powerful thing to be able to buy an app on your phone, and then being able to use it on your PC or your Xbox.
I am looking forward to my semester in SBR600, and hopefully involve myself in the Fedora and open source community further!
-Richard K.
What would you RISC?
professorplumpi 
Recent Comments