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.
Thursday, December 3, 2009
Tuesday, November 17, 2009
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.
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.
Tuesday, November 10, 2009
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!
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!
Thursday, November 5, 2009
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.
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 :).
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 :).
Saturday, October 17, 2009
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:
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!
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!
Subscribe to:
Posts (Atom)