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.