Viewsource Modifications

viewsource-1.1-1.fc11.noarch.rpm

The first release of viewsource had a lot of bugs, I accidentally installed the files in the wrong directory, /usr/bin because I never really grasped the macros until recently. I realized that these files needed to be built in /var/www/html directory because they had to be accessed by the web browser. Another issue was we did not have a working version of dojo.

viewsource-1.2-1.fc11.noarch.rpm

Issues from the first release were addressed and the install directory looked like so:

%install
rm -rf %{buildroot}
install -d %{buildroot}/var/www/html/viewsource
install -p viewsource.py %{buildroot}/var/www/html/viewsource
install -p viewsource.config %{buildroot}/var/www/html/viewsource
install -p index.html %{buildroot}/var/www/html/viewsource

likewise with the files section looking like:

%files
/var/www/html/viewsource/viewsource.py
/var/www/html/viewsource/viewsource.config
/var/www/html/viewsource/index.html
/var/www/html/viewsource/viewsource.pyo
/var/www/html/viewsource/viewsource.pyc
/etc/httpd/conf.d/viewsource.conf
%defattr(-,root,root,-)
%doc LICENSE

Notice viewsource.pyo and .pcy those are just results of the compiler.
Next we needed to fix the dojo issue, so a patch was made which would add the dojo that google uses and has made available to the public. This fixed the dojo issue.

Other issues arose, now that we have the viewsource html doctument and can view it through a url we tried hitting the buttons at the bottom to see if they worked, all they did was grab python code and bring it to the screen it didnt actually run it.

Viewsource-1.3-1.fc11.noarch.rpm

We thought that we had to make a config file in httpd.conf to Addhandler cgi-script .cgi. It looked like so:

%install
rm -rf %{buildroot}
install -d %{buildroot}/var/www/html/viewsource
install -p viewsource.py %{buildroot}/var/www/html/viewsource
install -p viewsource.config %{buildroot}/var/www/html/viewsource
install -p index.html %{buildroot}/var/www/html/viewsource
install -d %{buildroot}/etc/httpd/conf.d
install -p %{SOURCE1} %{buildroot}/etc/httpd/conf.d (this is the added apache conf file)

We thought this would work but for some reason the same thing happened, we still need to work this out. To be continued.

Packaging Viewsource

For this project each member of the class was assigned something to do. Boris Chao and Adam Hilts were to package Dehydra and Jshydra, I was to package Viewsource, and Alex was to make the repo. At the moment the other classmates tasks elude me.

I started out wondering where I even get a tar file for viewsource so I was told I had to go to the viewsource directory. Downloading all these files and then putting them into a tarfile would have been a lot of work and time but I decided to do it UNTIL I found that there was a viewsource.tgz in scotland. In the interest of time and work I decided to use this. I made my spec file, with a certain difficulty I might add.

Chris Tyler, my professor, told me through IRC
"So you could tar these up and use that as
Source0, have an empty %build section, and then
custom-install files in the %install section (see
the nled spec file if you need to see how to do
that)."

So I used this tip to help make my spec file. I

My specfile can be found here.

The real issue I had was that my setup section looked like %setup -c -T when it should have looked like what I have there now. After this I had an issue that said certain files were installed but not unpackaged so all I had to do was add those files to the %files section.

After I finished this, I put my RPM into hongkong's /var/www/http directory and can be accessed here for the repo master to get.

Viewsource Rpm

That's all for now, cya later.

G++ and Modified G++

First thing we had to do was download a script called build-tools.sh, shortly after I started running the script I was told there was a revised version where some change was made to it so we were supposed to use that one. This revised version can be found here. This time running the script was much faster but I ran into a little problem.

Error: installation or configuration problem: C++ compiler cannot create executables. I asked chris tyler about this on IRC and he said "ctyler> well, someone deleted the c++/g++ links", so whoever was on scotland last doing this, this is your fault! :P lol

After I remade the links using the commands:
su -c "ln -s /usr/bin/g++.original /usr/bin/g++"
su -c "ln -s /usr/bin/c++.original /usr/bin/c++"
it started running again doing its compiling thing.

Someone decided to compile something at the exact same time and it was severely slowing down my compile so I decided to use the hongkong machine.
That presented a new problem, apparently the gcc symbolic link wasnt done correctly so I had to fix that AND the c++.original file was tampered with so Chris Tyler had to fix that.
After these were fixed I could finally move on.

Apparently everyone decided to use the Abiword because it had a lot of c in it, so I decided to use it as well, I used the command "yumdownloader --source abiword" and then "rpm -i abiword*".

After fiddling with dependencies I ran: time rpmbuild -ba abiword.spec three times and came out with this:

Using Original g++

Test 1 - real 7m11.373s
user 10m8.225s
sys 3m5.116s

Test 2 - real 3m58.134s
user 3m27.638s
sys 2m6.875s

Test 3 - real 3m56.867s
user 3m28.087s
sys 2m7.464s

Test 4 - real 3m56.037s
user 3m27.520s
sys 2m7.851s

Four tests were done because the first test seemed exponentially longer than the others.
Now its time to use the modified g++. I had to create a symbolic link to my modified g++ I did so with this command

su -c "ln -s /home/jddeni/tools/gcc-dehydra/installed/bin/[gc]++ /usr/bin"

I ran the build command again and here are the outputs:

Test 1 - real 6m38.812s
user 10m0.445s
sys 2m53.160s

Test 2 - real 3m31.770s
user 3m17.512s
sys 1m56.154s

Test 3 - real 3m31.757s
user 3m17.073s
sys 1m55.958s

Test 4 - real 3m29.787s
user 3m16.585s
sys 1m56.548s

As you can see in all of the cases the modified g++ produced faster results.
Nobody worry, I am putting the symbolic links backk in to their originals :)

Until next time!

Fedora Live CD

Since I was so busy during reading week I did not get a chance to do the fedora live CD until very recently. I first went to the seneca wiki page and found links on how to do the live cd.

Using the live cd how to I tried the sample command there to see if it would work and it did, it started making a live cd but I had to make my own personal version so I stopped the process.

I first had to get a kickstart file to edit, I looked in the /usr/share/spin-kickstarts/ directory where i found fedora-livecd-desktop.ks, I then issued the command "cp fedora-livecd-desktop.ks /home/jddeni/" to save it to my home directory.

Before the %packages section I put a repo command to add the rpm from it into the live cd.

repo --name="jddeni" --baseurl=http://scotland.proximity.on.ca/jddeni/

In the packages section I took out the fedora branding and put my own by placing these lines in the kickstart file:

# add generic branding
generic-release
generic-logos
generic-release-notes

#Remove Fedora Branding
-fedora-release
-fedora-logos
-fedora-release-notes

When I ran it the first time using the command

livecd-creator --config=/home/jddeni/fedora-livecd-desktop.ks --fslabel=Refuge Live Cd --cache=/var/cache/live

it stopped working saying it couldn't find my package, I was completely confused about this because there were no typo's or anything. I later realized, due to Chris Tyler's help, that when I put the entire filename, jddeni-release-1-1-fc10.noarch.rpm it won't work, so I had to take off the 1-1-fc10.noarch.rpm and leave it as just "jddeni-release" and luckily it worked.

The whole process lasted about half an hour to make but it finally worked, I now have Refuge.iso and plan on putting in on a cd soon.

FSOSS 2009

So, I decided to sign up for the volunteering before FSOSS. Originally I believed that we were going to stuff bags with shirts and whatnot, however when the week approached I received an email that the Tuesday, should I choose to come in, we were going to be created the badges for FSOSS.

All throughout the reading week I was at training for a new job in Mississauga so I was pretty booked up, I decided to go to volunteering on the Thursday.

Thursdays job was pamphlet folding, after folding so many sheets someone in the office found a typo and we were asked to refold all of them. Since I had to go back to training for 3 pm - 9pm I had to leave and the rest of the folding job went to Alex V and another person.

They had so much folding to do, I am sort of glad I had training haha.

I came to FSOSS kind of late as I had something to do in the morning but I did pick up my shirt which was a bonus :).

Repository

Using a combination of bad notes and the Seneca Wiki SBR Page along with some of Boris Chao's notes I started the process.

After inputting all the correct information it started to generate the key. However a small issue arose:

Error: "Not enough random bytes available. Please do some other work to give
the OS a chance to collect more entropy! (Need 262 more bytes)" at first I thought, "Great another error, can't this go easy for once?" but then as I typed and did more random work on the computer the error went away and it continued its work. *phew*

Public and secret key now created and signed, and I am happy so far.

I then continued on with the notes on seneca wiki and Boris' notes and went on to create a .repo file. I used a template from the /etc/yum.repos.d and edited it to have the following information:

[]
name= repo for $releasever - $basearch
baseurl=
i.e. http://exmaple.com/repo/
#failovermethod=roundrobin
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/


After I finished this I put it in the /rpmbuild/SOURCES directory along with my key.

Then I made a spec file for my repository. After this ran successfully it created a file
called jddeni-release-1-1.fc10.noarch.rpm.

After adding a simple html page, this is what it looks like.





Here is my page.

Don't let repositories intimidate you, the hardest part is prepping everything
for the repositories, once it is prepared creating it in no problem.

Rpmlint, mock and koji

Well well my good friends, I am glad to say that ettercap has finally been defeated! *cheer*

Well after I decided to build on a 64-bit machine (Scotland) my weird debug errors seemed to go away when using rpmlint, instead I got a stack error which, after explained to my by Chris Tyler, I could do nothing about because that is just how ettercap was coded. After the rpmlint worked everywhere else I decided to go to the next level....mock.

After running mock I got errors and started to pull my hair out, but then I realized that it was only a few dependency issues. (Note: These same dependency issues were causing me grief on my home machine, but somehow went away on scotland). After I added the buildrequires everything worked.

The next step was koji. Using the Koji Fedora How To page I used the following commands:

1) yum install fedora-packager
2) /usr/bin/fedora-packager-setup
(after running this command it told me to get a certificate from koji.
3) Ran /usr/bin/fedora-packager-setup again and it worked, I just had to add an export password and I was done.

Now, to upload it to the koji server!

Using the command koji build --scratch dist-11 ettercap-0.7.3-1.fc10.src.rpm
it started uploading to koji and building on each architecture. To my surprise everything worked!

Next step....repositories!

Does the -j option really matter?

In class we decided to make a script t0 build a certain big package multiple times using different -j values to see if they had any affect on the time it took to build the package. I chose the pingus package. Despite the idea that using more cores to do the job should theoretically speed up the process, my output shows quite the opposite. Running the same -j value three times came up with different results each time. The fact that these results were different each time could probably be due to the fact that other people may have also been using the resources of my specific computer at the same time. As you can see in the bar graph the average time taken to compile this package is around 5 minutes and this doesn't seem to change no matter what -j value is used. The remaining two build runs for -j9 were not done because I lost connection, however due to the trend it is safe to assume they would have been the same.

For the pingus package, the -j value does not have a significant effect.

*MASSIVE SIGH* Spec file....

*sigh* Where do I begin?

Well I learned how to write a simple spec file first after getting the rpmbuild directory. I chose ettercap to build from the spec file and I guess that was not the wisest choice but I stuck with it.

I first had an issue with the ettercap version since it doesnt start with a number it starts with a letter, Ettercap-NG-0.7.3. I simply had to add "%setup -q -n ettercap-NG-0.7.3" to the prep section with the "-n" allowing the letters.

Secondly I had an issue with O_CREAT only having 2 parameters and needing three, after searching countless forums I found out that this was a bug and needed to be fixed using patches. (https://bugzilla.redhat.com/show_bug.cgi?id=330971) I then searched for all the ettercap patches I could, added them to my SOURCES directory and put a section in my specfile to allow for patching. http://cvs.fedoraproject.org/viewvc/F-11/ettercap

My next issue was that in the %files section I had %{bindir}/* when it gave me an error I changed it to %{_bindir}/*. After this I got a whole bunch of packages that were installed but still unpackaged. To solve this I added %{_datadir}/*,
%{_libdir}/*, %{_mandir}/*.

The binary then showed up in the RPMS directory and I ran rpmlint. I had a bunch of errors that I could not fix (I spent a lot of time.) I then decided in another rpmbuild directory to look at what the actual spec file for ettercap should look like for it to run perfectly with no errors, it was huge. http://cvs.fedoraproject.org/viewvc/devel/ettercap/ettercap.spec?view=co

*sigh* Why did I choose ettercap...

Telephone conference with Jesse Keating

On Thursday my SBR600 class took a trip to the conference room in the Tell building to have a phone conference with Jesse Keating, a Fedora Release Engineer.

I found this conference to be very informative, Jesse was very clear and quite knowledgeable. I was quite interested to learn about the release process, containing such things as the alpha release stage, the beta release stage, and then the final release. I was also pleased to learn that fedora 12 is in between the Alpha release and the Beta release stages.

All of the questions I had come up with during the conference were pretty much answered by Jesse without me having to even ask. Even though it is a personal question I am still quite interested to know how much he makes.

For anyone interested in learning a little bit about the fedora release process and other fedora related topics you can at: http://cdot.senecac.on.ca/audio/sbr600/

Configure, Make, and Make install

Installing NLED from source.

I downloaded this using wget and it didn't have a configure feature so I used make right away. When using the make command I received an error saying that I was missing ncurses.h,so I had to go and download the ncurses package and configure it to my system, make (which took a while), and then make install. After I had this package fully installed I re-ran make for NLED and everything worked.

Installing Ettercap-NG-0.7.3 (Sniffer)

I downloaded this using wget (link location). I had to configure this before I could run make. The first issue was that libpcap was not found, so I had to search on google and downloaded libpcap0.8-dev.

The second issue was that libnet not found, this was a particularly annoying problem because after trial and error and google research it would seem that this version of ettercap was dependant on ONLY libnet1.1.2.1 even though it said I could get a higher version. So after downloading a higher version and failing I had to download libnet1.1.2.1.tar.gz .

Lastly, I had to configure ettercap, make, and make install it. It installed into the /usr/local directory so I just moved the executable file over to my home directory and was able to run it. You have to specify whether you want to view it in text mode or in Ncurses mode or GTK mode with -T -C -G respectively.

An Introduction to SBR600

Hello, my name is Jonathan. For all of you who don't know me I am a student in Semester 5 currently taking Chris Tylers' course coded "SBR600". The class sounds very interesting and I look forward to what is in store this semester. The following is a cut out of a message we had on Xchat just verifying if everything works:

X-Chat

ctyler: ping
jdeni: pong
ctyler: Hey Chris, I was just wondering if you were in class or something. Just making sure this all works
ctyler: jdeni: I'm down in my office. Seems to work fine!
What IRC client are you using?
I decided to go with xchat, however I am not really fond of the layout compared to the one you showed us.
its similar but for some reason, I can only open a window per channel, unlike how yours had all the chanels in one window and you could just choose from them
ctyler: jdeni: I was using xchat :-)
jdeni: ctyler: haha I was afraid you would say that, any idea how I can put all my chanels into one window? Right now I have a window for freenode and a window for mozilla
i'm using the channel-switcher, in 'tree' mode (vs. 'tab' mode)
jdeni: okay thanks
jdeni: That got one issue sorted out, however I will show you in class tommorow what I mean by the different windows
jdeni: ctyler: I was just informed I have to make dinner, I will see you tommorow, thanks for the help!
ctyler: see you

Seneca Wiki's User Page Link

http://zenit.senecac.on.ca/wiki/index.php/User:JonathanDeni

Fedora Wiki's User Page Link

https://fedoraproject.org/wiki/User:Jdeni