Anthony Boccia's OpenSource Blog

FSOSS/Linux Fest 2011 - My Teams Presentation

2012-01-10T23:06:00.000-08:00

Yes, it has been a while since I last threw a post up here, I am still alive. I recently graduated :-) and am seeking a job in RedHat Based system administration...But enough of my begging for work. Below you'll find the FedoraARM development team presentation on running a build farm with Fedora on ARM. We Presented at FSOSS 2011 (Free Software and Open Source Symposium) in October. Just now the video was posted. It is a slideshow with voice over so don't expect to many explosions...or any. I hope it will serve well to educated and offer insight to the advancements and the effort towards the on going development of the Fedora Distribution of Linux in the ARM world.

ARMHFP Builders Via Chroot

2011-11-28T07:26:00.000-08:00

Recently our Buildfarm http://arm.koji.fedoraproject.org has been upgraded to include ARMV7HL builder support. This was achieved by creating a Fedora 15 Arm chroot on our Pandaboards.

Here are the steps taken:

Prep - Download the completed rootfs, and chrootfs:
RootFS: http://iraq.proximity.on.ca/v7chroot/PANDABOARD/rootfs.tar.gz
Boot: http://iraq.proximity.on.ca/PANDA/boot.tar.gz
ChrootFS: http://iraq.proximity.on.ca/v7chroot/PANDABOARD/v7chroot-final-certless.tgz
MakePandaScript: http://iraq.proximity.on.ca/PANDA/makepanda

Steps for PandaMainroot
1) run the makepanda script on your SDcard, this will create the necessary partition scheme. This should be complete, at this point.

2) Mount the boot partition and explode the boot tarball to it.

mkdir tmpmnt
mount /dev/carddev1 tmpmnt/

tar xfv boot.tar.gz -C tmpmnt/

sync

umount tmpmnt/

3) Follow the same process for the rootfs

mount /dev/carddev2 tmpmnt/

tar xfv rootfs.tar.gz -C tmpmnt/

sync

umount tmpmnt/

4) Place the card in the panda and power it on, if you make it to the login prompt your good to go, login with password fedoraarm.

Note: That you will have to manually setup your networking, as this is currently done via a script in the rootfs, and will not work outside of our farm, some custom tweaking will be necessary . The chroot will still function just fine for building V7HL with mock, provided you have the correct mock config in place. ping fossjon in #fedora-arm for more info.

Steps for Chroot Creation
1) Install the rootfs onto your pandaboard

2) Explode chroot archive into rootfs like so

tar xfvj v7chroot-final-certless.tgz -C /

3) Copy Main root resolv.conf to chroot

Note: This is done to ensure the chroot has DNS info, the ip will be shared via main rootfs

cp /etc/resolv.conf /path/too/chroot/etc/resolv.conf

4) Test connectivity with: ping yahoo.ca

5) Add the following(6,7) to the main rootfs /etc/rc.d/init.d/koji-config

Note: The koji-config is a script executed at boot time to prep and enable the pandaboard in our build environment, it is native to our set up, yours may differ.

6) Setup bind Mounts from Local root to Chroot

mount -t proc chroot_proc /home/v7chroot/root/proc

mount -t sysfs chroot_sysfs /home/v7chroot/root/sys

mount -t devpts -o gid=5,mode=0620,ptmxmode=0666,newinstance chroot_devpts /home/v7chroot/root/dev/pts

mount -t tmpfs chroot_shmfs /home/v7chroot/root/dev/shm

mount --bind /var/cache/mock/fedora-15-arm/ccache/ /home/v7chroot/root/tmp/ccache

mount --bind /mnt/koji /home/v7chroot/root/mnt/koji

mount --bind /fs0 /home/v7chroot/root/fs0

mount -o bind /dev/ /home/v7chroot/root/dev

7) Change Kojid config in chroot to the correct hostname for user= and create the correct sym link to the kojid cert for the builder
Note: This step is only necessary for a fedora-arm koji setup, it can be ignored if builder will not be included in koji.

sed -i "s/^user *=.*$/user = $(hostname)-v7hl/" /home/v7chroot/root/etc/kojid/kojid.conf

ln -s /etc/kojid/certs/$(hostname)-v7hl.pem /etc/kojid/localhost.pem

8) Start the Chroot

chroot /home/v7chroot/root

9) You can setup in a startup script a command to start the chroot, and kojid within like so: chroot /home/v7chroot/root/ /sbin/service/ kojid start &

10) Finally, if you wish to have your panda as part of the build effort, ping aeboccia,fossjon,frojoe,ctyler in #fedora-arm on Freenode IRC

Efika Smarttop MX51 - 3.0.4 Kernel

2011-10-21T10:58:00.000-07:00

It is with great excitement that i finally announce a completed 3.0.4 kernel for Efika MX Smarttop ARM Systems. Currently we have nine efika's active in our build farm, they are building packages under mock for our F15Arm release; and are currently running the most up to date stable kernel.

Some Minor tweaks, specific to the Fedora-ARM team setup which have been built into the kernel include, IPV6 support and ACL's on ext2,3,4 filesystems. Another large tweak, was scaling back the version number to 2.6.40. This was necessary as some packages look for kernel version 2.6* when building.

Below are links to the built uImage, module tarball, and the config used to build the kernel.

3.0.4-Config-mx51
Modules-2.6.40
Completed uImage

That's all for now. Stay tuned,

SHARPY

Sigul Signing Server

2011-06-16T11:19:00.000-07:00

Welcome to another OpenSource post,

This week I was finally able to get a sigul signing server up and running, for CDOT's fedora arm project. Currently we are signing 25835 RPM's for our F13 -Arm release. There is not a whole lot to post here, as the major part of this task was documentation. If you click here you can view my step by step documentation created to allow anyone to setup their own sigul instance.

Stay tuned,

ATI - Catalyst Drivers with Akmod + Watermark Removal

2011-05-18T18:38:00.000-07:00

As many know ATI support is not the greatest on Linux, well at least not as far along as Nvidia support, so it can sometimes be tricky getting your ATI drivers to function especially if they are of the HD Mobile chipset variety.
I have an Asus K52JT model laptop, it's an affordable and well performing I7 but it did come with one price, it has a HD6370M gfx card. It's not a bad card but for a Fedora user it presents a challenge. The following is the walkthrough of the steps to install akmod and remove the pesky Unsupported Hardware watermark that may appear.

Open a terminal and SU to root next issue: yum install akmod-catalyst

*After install the drivers reboot the system

Upon booting up, you may notice a Small Watermark to the bottom right of the screen which reads:

AMD
Unsupported Hardware

This watermark tends to show up when the graphics drivers installed do not want to play nice with your hardware, essentially thinking it's not installed though it is. This is not a problem, to test and make sure that the drivers are indeed working perform the following:

Open a terminal SU to root and issue: glxgears

*Note you should see some FPS rates being generated, this means your gfx drivers are installed and functioning

After ensuring the graphics drivers are functioning it's time to remove the watermark. I found a script to do so posted here, and after some minor modification for my system it ran successfully and removed the watermark.
Create the following script

#!/bin/sh
DRIVER=/usr/lib64/xorg/modules/drivers/fglrx_drv.so
for x in $(objdump -d $DRIVER|awk '/call/&&/EnableLogo/{print "\\x"$2"\\x"$3"\\x"$4"\\x"$5"\\x"$6}'); do
sed -i "s/$x/\x90\x90\x90\x90\x90/g" $DRIVER
done

The original source can be found here. I had to modify the top line to lib64 from lib, the best way to check if you need to would be to search for that fglrx_drv.so find its directory and change the top line as per your situation.

Execute the script, and reboot. Upon boot you should no longer have the watermark problem :-)

Thanks for reading, Stay tuned.

PandaBoard - XSession with Firefox On F13beta3

2011-05-17T12:57:00.000-07:00

Welcome,

The following is a walk through on how to install graphics drivers, xorg and firefox, on a panda board running Fedora-Arm 13 beta3 release, and configure it to open an X session with Firefox to display a desired page on boot. For CDOT purposes it displays a Status Dashboard web page on an external monitor.

1. Boot up your pandaboard and login

2. Issue command yum install xorg*

This installs all available, fonts, and other things needed for X to function, without a desktop environment, essentially just XSERVER.

* The specific driver in use is omapfb, and is available in the cdot fedora-arm repo's. If you wish to specify solely the xorg base system and single driver you can.

Optional: If you want you can install a Window manager, I did for testing purposes as it was annoying not being able to close more move windows. I used icewm, installed with yum install icewm. But you can use any window manager it's your choice.

3. vi /etc/X11/xorg.conf and add the following:

Section "ServerFlags"
   Option "IgnoreABI" "True"
EndSection

Section "Device"
    Identifier "Card"
    Driver "omapfb"
EndSection

Section "Screen"
Identifier "Screen0"
Device "Card0"
Monitor "Monitor0"
Subsection "Display"
Depth   24
Modes "1024x768"
EndSubsection
Subsection "Display"
Depth   32
Modes "1024x768"
EndSubsection
EndSection

* You can edit the Modes as you wish depending on the monitor size you have and what you prefer.

4. Reboot the system

5. Next install firefox the latest for arm being 3.6: yum install firefox

6. Next for a quick test of X and firefox issue the following:

export DISPLAY=:0

xinit /usr/bin/firefox http://www.google.ca & <--This should open display :0 with a terminal and a firefox window.

7. Getting the window to display on boot will require two things, the first being a javascript html file, which I found easiest for my purposes and should be just fine for any other instance. The scripts to do this were written for me by Jon Chiappetta, they are displayed here.

Once you have created the popup.html file you can begin to write a service for your Dashboard to start on boot.

8. First create a service script file, to boot the Xdisplay and firefox on boot

vi /etc/init.d/servicename <--pick a name...any name

Add the following to the file

#!/bin/sh
#
# CDOT-Service Status notification daemon #<-- Change this to reflect your service info
#
# Author:       Fedora_Arm team #<-- Change this to reflect your authors name
#
# chkconfig: 2345 98 20
#
# description: This is the status board service \   #<-- edit the description as you desire.
#               For CDOT Dashboard
# processname: zdotstats #<-- Match your service name, so it is easy to identify in the process list
#
RETVAL=0;
start() {
echo "Starting YourService"
export DISPLAY=:0
#We login as root, as it is the only user we have on the machine, and nothing critical is hosted.
export USER=root
export HOME=/root
xinit &
killall firefox
rm -f /root/.mozilla/firefox/i7l6qmmk.default/sessionstore*
/usr/bin/firefox http://yourhost.com/popup.html &
}

stop() {
echo "Stopping your service"
pkill xinit
}

restart() {
pkill xinit
/usr/bin/xinit &
}

case "$1" in
start)
start
;;
stop)
stop
;;
restart)
restart
;;
*)
echo $"Usage: $0 {start|stop|restart}"
exit 1
esac

exit $RETVAL

9. Issue command: chkconfig --add servicename
           chkconfig servicename on

* This will add your service to the list of services and turn it on for all run levels, if you want you can specify using the --levels option.

10. Test the service with command: service servicename start
If all is well, your x session should start and open your popup page in firefox automatically.

11. Finally reboot your system, and if all is in good order your X session should start and open firefox to your popup page on boot.

0.3 - Nothing new since 0.2 But More to come

2011-04-26T22:10:00.000-07:00

Hello All,

Yes i am late with my 0.3 report release, since hongkong has had much downtime I have been unable to test full builds on the Italy koji system since the repo it relies on is not functioning at the moment. I plan to soon post timings and results with builds on fully arm supported build system, with hongkong up and running. Stay tuned.

First BUILD on Open-RD Koji - 0.2

2011-03-28T12:53:00.000-07:00

I have done it...finally, a couple of days ago i posted that i finally had koji up and running on the Open-RD system and needed to grapple with kojira next, to get repo's setup. Finally after a couple of days, I was able to build a src.rpm for filezilla, with a wonderful green complete within a few seconds; this is excited not only because I am finally %99.99 complete on my journey with Koji and ARM, but because the build showed that the setup between the two arm systems Open-RD(HUB/WEB) and GuruPlug(Builder) proves very efficient for builds. That being said, I find the web interface is still a tad to slow for my liking, and i plan to soon begin researching more efficient ways for it to function...not to jump to a conclusion but placing koji-web on a separate dedicated arm machine may be a great option, and i hope i can obtain the resources to begin testing this theory.

One thing to note, is that the koji how-to documentation does not outline how to go about the repo setup, however it does provide a link that does. ServerBootstrap Is the walk through i followed to get base tags setup that are required for build's to function. It was straight forward and believe it or not for once i had no error troubles.

That's all for now,

Stay Tuned

Koji + 1 Builder Running on Open-RD

2011-03-26T09:17:00.000-07:00

It is with great excitement that I announce the installing of the koji build system running on an ARM based platform. After a few days which followed a few months of grappling with koji and it's howto guide, I was able to get koji web and hub up and running on an Open-RD system, with one attached koji builder Guru Plug.

http://italy.proximity.on.ca/koji
||
Open-RD <--PrivateLan-->GuruServerPlug

Koji-Hub Koji-Builder

Koji-Web

Above is a more visual breakdown on whats running what. So far the builder is able to communicate with the hub and all Lights are green :-). Next step is to create the kojira repo, and in the following week I will begin testing the building of packages to see what the speeds are like, with builds, web interface, and the Open-RD itself. This should allow for further determination on what types of tweaks can be made to ensure an efficient as possible, fully ARM supported build farm.

Stay Tuned!

Kojiadmin CN=fqdn Mixup

2011-03-22T18:23:00.000-07:00

I was able to solve my server certificate error from before, but the next error proved a little bit tricky and took me a couple of days to figure out the fix to. When attempting to issue admin level commands with the kojiadmin user I was faced with ActionNotAllowed: admin permission required

What could be causing this? I thought. The certs were all in the right spots but for some reason I could still could not issue admin commands, the apache error_log reported the following:

/usr/lib64/python2.6/site-packages/mod_python/importer.py:32: DeprecationWarning: the md5 module is deprecated; use hashlib instead

import md5

2011-03-15 15:41:44,145 [WARNING] m=createUser u=iraq.proximity.on.ca koji.xmlrpc: Traceback (most recent call last):

File "/usr/share/koji-hub/kojixmlrpc.py", line 191, in _marshaled_dispatch

response = self._dispatch(method, params)

File "/usr/share/koji-hub/kojixmlrpc.py", line 253, in _dispatch

ret = func(*params,**opts)

File "/usr/share/koji-hub/kojihub.py", line 7867, in createUser

context.session.assertPerm('admin')

File "/usr/lib/python2.6/site-packages/koji/auth.py", line 527, in assertPerm

raise koji.ActionNotAllowed, "%s permission required" % name

ActionNotAllowed: admin permission required

Solution:

For some reason iraq.proximity.on.ca was auto added to the psql database, when giving it admin permissions kojiadmin could add users----Possible cert issue?

I regenerated certs, and found it was occurring due to the CN being set as iraq.proximity.on.ca with the kojiadmin cert. It was attempting to authenticate the fqdn instead of the OU with was kojiadmin.

By regenerating the certificates for kojiadmin and making the CN=kojiadmin with a blank OU the error no longer occured, and kojiadmin was able to be authenticated to add users or perform other administrative tasks on koji with the kojiadmin user.

Koji Cert FUN!

2011-03-22T17:48:00.000-07:00

The generation of the certs, though it is tedious, it's not to painful so long as you understand exactly how they function between koji hub, and ssl for user authentication. I learned how they interacted with certs the hard way, the first main issue i ran into was far into the configuration of koji when issuing the add-user koji command i was faced with the following:

Command: koji add-user kojira

Error:

[('SSL routines', 'SSL3_GET_SERVER_CERTIFICATE', 'certificate verify failed')]

Solution:

Apache may be pointing to the incorrect certs for ssl authentication, in my case my apache ssl configuration was looking in /etc/pki/tls/certs/localhost.crt for the server cert and /etc/pki/tls/private/localhost.key for the server private key.

This can be fixed two ways, either by changing apache ssl to point to your koji_ca_cert.crt and koji_ca_cert.key files

ssl.conf (Option 1)

#   Server Certificate:
# Point SSLCertificateFile at a PEM encoded certificate. If
# the certificate is encrypted, then you will be prompted for a
# pass phrase. Note that a kill -HUP will prompt again. A new
# certificate can be generated using the genkey(1) command.
SSLCertificateFile /etc/pki/koji/koji_ca_cert.crt

#   Server Private Key:
#   If the key is not combined with the certificate, use this
#   directive to point at the key file. Keep in mind that if
#   you've both a RSA and a DSA private key you can configure
#   both in parallel (to also allow the use of DSA ciphers, etc.)
SSLCertificateKeyFile /etc/pki/koji/private/koji_ca_cert.key

Or by leaving the SSL configs to defaults and copying koji_ca_cert.crt to /etc/pki/tls/certs/localhost.crt and overwriting it and doing the same for the private key by copying the koji_ca_cert.key to /etc/pki/tls/private/localhost.key

Commands (Option 2):

cp /etc/pki/koji/koji_ca_cert.crt /etc/pki/tls/certs/localhost.crt

cp /etc/pki/koji/private/koji_ca_cert.key /etc/pki/tls/private/localhost.key

Through this problem I was clear on how koji authenticates its user which is sending commands in this case from the CLI with apache SSL, the user kojiadmin does not just have to have a config file with pointers to the correct certs, the server certificates must point to the valid koji_ca generated certificate authority cert since the koji setup creates a standalone cert auithority. The certificates were definitely the most challenging part of this config as they spread across multiple aspects of koji, and must be configured in line with the other parts of Koji in order to flawlessly function.

Adventures in Koji

2011-03-13T15:16:00.001-07:00

Hello, All

Okay so it has been long overdue that I post something, recently I have been going about the process of installing the Koji Build system on Fedora 13. So far it has been a bit of a headache, fun, and a great learning experience. The next several posts will outline step by step what I have done so far, the errors I encountered and how I went about fixing them. Throughout my adventure in Koji I have been following the fedora wiki walk through, which as many may already know is a great guide, but doesn't really go to in depth on the install process, and the common issues some may face, so for some added help to any others who may be on the same road as me or same road block as I once was with this process, I will be trying to be as detailed as possible as I post each step of my adventure with Koji.

Koji Hub on ARM

2011-02-03T08:12:00.000-08:00

Hello All,

Been a while i know, recently i created my project page for the work i will be doing on the implementation of Koji or the Open-RD Hub. Here is a link to my wiki for the project, I will also be blogging as often as i can to keep you all posted on the progress. If any of you would like to help or have some ideas please let me know either by comment or emailing me.

Stay Tuned...

Koji Hub on ARM

My First RPM Build

2011-01-24T11:29:00.000-08:00

Hello All,

Finally I have reinstalled my system resolving the many issues that i had with compilers and whatnot due to my escapades with ATI, I finally was able to build my macchanger and httptunnel. Please join me now as i take you through my adventure of my first RPM builds :). The first packaged i built was http tunnel, i created the default spec file and filled in all required fields for my package. It is a simple app so the build went very smooth, aside from one error which i had after executing rpmlint on the package:

rpmlint ../RPMS/x86_64/httptunnel-3.0.5-1.fc14.x86_64.rpm
httptunnel.x86_64: W: incoherent-version-in-changelog [3.0.5-1.fc14] ['3.0.5-1.fc14', '3.0.5-1']
1 packages and 0 specfiles checked; 0 errors, 1 warnings.

No matter what combination i seemed to try with the version in the changelog i could not seem to get a correct one, despite all suggestions from IRC and Google :P. Rest assure i have not given up and will post my solution as soon as it is found.

So httptunnel went relatively well, so how hard can macchanger be? Well i jinxed myself with that question.

Macchanger required some extra research and tweaking of the spec file, to resolve issues with info files, and man files. Not to worry a quick Google of the following errors actually brought me to the CDOT feed where a fellow member of SBR600 was having the same issue, I followed the steps they had taken and my issue was resolved :P

RPM build errors:
    Installed (but unpackaged) file(s) found:
   /usr/bin/macchanger
   /usr/share/info/dir
   /usr/share/info/macchanger.info.gz
   /usr/share/macchanger/OUI.list
   /usr/share/macchanger/wireless.list
   /usr/share/man/man1/macchanger.1.gz
These errors were resolved by adding the above full path files to the %docs section of my spec files and the package built successfully but soon i ran into the follow with rpmlint
--------------------------------------------------------------------------
rpmlint ../RPMS/x86_64/macchanger-1.5.0-1.fc14.x86_64.rpm
macchanger.x86_64: W: no-version-in-last-changelog
macchanger.x86_64: E: info-files-without-install-info-postin /usr/share/info/macchanger.info.gz
macchanger.x86_64: E: info-files-without-install-info-postun /usr/share/info/macchanger.info.gz
macchanger.x86_64: E: info-dir-file /usr/share/info/dir
macchanger.x86_64: E: info-files-without-install-info-postin /usr/share/info/dir
macchanger.x86_64: E: info-files-without-install-info-postun /usr/share/info/dir
1 packages and 0 specfiles checked; 5 errors, 1 warnings.

These errors were repaired by following these steps:
1. Add the following under the Requires section of the spec file

Requires(post): info
Requires(preun): info
...
%post
/sbin/install-info %{_infodir}/%{name}.info %{_infodir}/dir || :

%preun
if [ $1 = 0 ] ; then
  /sbin/install-info --delete %{_infodir}/%{name}.info %{_infodir}/dir || :
fi

*"These two scriptlets tell install-info to add entries for the info pages
to the main index file on installation and remove them at erase time.  
The "|| :" in this case prevents failures that would typically affect 
systems that have been configured not to install any %doc files, or have
read-only mounted, %_netsharedpath /usr/share." Source

2. Add the following under %install

rm %{buildroot}/%{_datadir}/info/dir

*This removes dir file after installation

By Adding these two lines my errors were all resolved minus the One warning which i am still chipping away at.

Stay Tuned for my Koji Experiences

Eventful Weekend, with ATI and Fedora 14 (A Short Story)

2011-01-16T20:06:00.000-08:00

Hello All,
I know it has been a bit since my last blog post, and i should have by now updated with my packaging lab, but something occurred this weekend with my install that cause me to take some time out of experimenting with RPM packaging and Recover my Fedora 14 system. Though the mistakes i made may seem quite silly, and the steps i took to recover may seem quite simple, I often think back to when I had first entered this wonderful world of open-source and Linux OS'es; the simplest of tasks seemed very intimidating and looking back now i chuckle at myself and am surprised at how far I have come, but am also aware of how far i still have to go. But i digress, the point i am essentially trying to make is I still feel the need to post the steps i took to fix what i broke, because I know that there are others out their who are starting off just as i did, looking for a simple walk through or detailed explanation for a specific fix, to let them get their feet wet, and learn from their mistakes...though they can always happen.

As most open-source users may know, ATI support hasn't always been the best, but development for it has come quite far in the last few years providing better support for drivers be it open-source or propriety. In the previous version of fedora, the ATI drivers functioned quite well both the opensource kmod and AMD's own. With the update of Laughlin, ATI and kmod drivers ceased to work, partially and in my case fully. I attempted to install the proprietor drivers for my HD6370 card, which from what i could tell utilized the 5000M chipset, though lspci could have been mistaken, regardless i obtained the drivers from AMD's page here.

The install is relatively straight forward a simple sh ati-yaddyadda.sh, the drivers appeared to compile and install just fine, even the catalyst control center appeared in my preferences menu; after a restart my smile turned to a frown as the drivers seemed to not have worked at all, and to boot catalyst reported no hardware present, after viewing this error i did what everyone does, opened firefox and began to google. I found that many people were having this issue with ATI and Fedora 14, some had reported the kmod drivers working, so i gave them a shot. I first uninstalled AMD's drivers and ran a yum install kmod-catalyst which installed the kmod ati drivers and the dependent xorg drivers and libraries, after the install i rebooted.

AND NOW THE HORROR BEGINS

After my system restarted OH NO i received a prompt a scary prompt, and intimidating prompt but a fixable one it was not a menu it was grub>. I promptly tossed in my fedora 14 install disc and booted up a recovery terminal from it, after logging into my install i noticed my grub.conf was wiped (let this be a lesson in frequent critical config backups). OH NO i thought, well not to worry; i remembered a trick, one simpler than manually re-editing my grub.conf. I started an upgrade install from the disc and had a new grub.conf generated, bless the developers who implemented this godsend of a feature so novice worshipers of the great penguin could have an easy way out :P. After booting up, the drivers ceased to function and i was presented with a flgrx64 kernel module not found error.

"What did you do?" you ask, well I yum removed kmod-catalyst which did indeed remove the kmod drivers. Upon restart once again I still had no GUI, hmmm it seemed any and all graphic drivers had been removed, now i am somewhat of a lazy person and if it's possible I will take the easy way out, then again who wouldn't? At this point i was done tinkering I'd broken enough so i issued a yum reinstall xorg* and to my amazement the godsend that is yum reinstalled my xorg including the native nouveau and ati drivers which allowed my system to function, i rebooted and am now writing this blog. Yes a long story, hopefully not boring but i felt the need to tell my open-source eventful weekend to the community, not only to explain that I now know I must wait for a fix to ATI drivers for laughlin, but just to share my various experiences in Open-source, like i have stated before through good and bad successes and failures.

Thanks for reading, and stay tuned for my next post on my experience with my introduction to rpm packaging...now that I have a functioning system i can get to work :P

Introduction

2011-01-13T08:17:00.000-08:00

Hello,

SHARPY here a.k.a Anthony Boccia. I am currently a student at seneca@york. I enjoy the admin side of fedora more since i am not the greatest at programming, all in all i find it to be one of the most fun, interesting, and well developed distro's. I have a few machines which i tinker with from time to time, and plan to post my experiences here to share with the community. Aside from my Tech life, i enjoy gaming, paintball, and sleep :P. Stay tuned and I hope you enjoy.

My Fedora Wiki Page

My CDOT wiki

Seneca learnID: aeboccia

IRCNick: SHARPY

<SHARPY> getting this output when attempting to run configure on macchanger: configure: error: C compiler cannot create executables
<billings> you probably need a C compiler.
<SHARPY> I have one gcc and g++ installed not sure, if its a config issue
* jsmith is now known as jsmith-busy
<billings> do yourself a favour and just install the development-tools group
<SHARPY> i have that as well
<billings> yum groupinstall development-tools?
<SHARPY> yep
<billings> well
<billings> then the next thing I'd suggest is that you fpaste the config.log
<SHARPY> will do
<billings> 'fpaste config.log' should work
* kc8hfi (~kc8hfi@157.182.181.230) has joined #fedora
<CosmicDJ> SHARPY: /tmp mounted noexec?
<mosno> nice, epel has fpaste
<SHARPY> http://fpaste.org/E4c0/
<billings> probably the best way to diagnose it is to look at the config.log in the same directory as the autoconf stuff
<SHARPY> im a noob, and did not fully understand what i was looking for
<billings> hah, it's /usr/lib/gcc/x86_64-redhat-linux/4.5.1/../../../../lib64/crt1.o: file not recognized: File truncated
<SHARPY> well then....
* fenrus02 directs billings to run: su -c 'yum install @development-tools @fedora-packager'
<billings> something odd is going on here
<billings> not me!
<fenrus02> billings, 'rpm -V' your way to finding out which packages are munged?
<jwildeboer> spot: error console says Warning: WebGL: Can't get a usable WebGL context
<jwildeboer> Source File: http://webglsamples.googlecode.com/hg/tdl/webgl.js
<DiscordianUK> Uggh why are all these people asking questions about compiling stuff
<billings> because some people actually compile code in fedora?
* DiscordianUK notes this is Fedora 13 and 14 end user support
* giarc (~cwt@fedora/giarc) has joined #fedora
<billings> yeah, well, in this case, I think there's something wrong witht he packages
<SHARPY> I shall direct my question elsewhere then, I appreciate the assitance billings, i'll look further into the packages. Thank You.
<DiscordianUK> billings : as do I but I don't bother here with questions I ask where I got the code from
* carl- has quit (Remote host closed the connection)
* rws (~rws@nat/ti/x-cjkohtspafczhgww) has joined #fedora
<billings> SHARPY: I *suspect* that you're going to need to look into why it's saying "crt1.o: file not recognized: File truncated"

Compiling GNU goodies (macchanger and httptunnel)

2011-01-12T11:37:00.000-08:00

Hello fellow OpenSource Guru's and Sheru's

Today's post will be outlining a few vanilla compiles of GNU apps i preformed and the steps i took to accomplish them; yes it may seem like simple stuff but it's always good to practice practice practice. Here we go.

1) I started off by first visiting the GNU software collection, to read up on some interesting apps and decide which to compile. The two which i decided on were httptunnel which is a handy simple app which allows for tunneling of data through a bidirectional virtual data connection disguised in HTTP requests. The second macchanger...in-case you are wondering, yes i like to try and remain as anonymous as possible on networks :P.

2) I acquired the tarballs from their developer's site which i found through the GNU page, the following are the commands taken for each compile.

[SHARPY@localhost tarballs]$ tar xzfv macchanger-1.5.0.tar.gz
real    0m0.016s
user    0m0.010s
sys    0m0.009s

[SHARPY@localhost tarballs]$ cd macchanger-1.5.0
[SHARPY@localhost macchanger-1.5.0]$ ./configure
real   0m2.436s
user   0m0.373s
sys   0m0.839s
[SHARPY@localhost macchanger-1.5.0]$ make
real    0m0.367s
user    0m0.238s
sys    0m0.112s

I attempted to run the compiled binary from then src/ dir where it compiled to, however i received this error:

[SHARPY@localhost src]$ ./macchanger
ERROR: Can't read MAC list file "/usr/local/share/macchanger/OUI.list", It looks like a bad installation
ERROR: Can't read MAC list file "/usr/local/share/macchanger/wireless.list", It looks like a bad installation

As a fix i switched to root and ran make install, as the install creates two files which are required for the application to function.

[SHARPY@localhost macchanger-1.5.0]$ su

[root@localhost macchanger-1.5.0]$ make install
real    0m0.440s
user    0m0.263s
sys    0m0.152s

The app then ran just fine:

[SHARPY@localhost macchanger-1.5.0]$ macchanger
GNU MAC Changer
Usage: macchanger [options] device

Try `macchanger --help' for more options.

Next I set out to compile httptunnel

[SHARPY@localhost tarballs]$ tar xzfv httptunnel-3.0.5.tar.gz
real    0m0.035s
user    0m0.024s
sys    0m0.018s

[SHARPY@localhost tarballs]$ cd httptunnel-3.0.5
[SHARPY@localhost httptunnel-3.0.5]$ ./configure
real    0m2.014s
user    0m0.428s
sys    0m0.443s

[SHARPY@localhost httptunnel-3.0.5]$ make
real    0m1.155s
user    0m0.850s
sys    0m0.275s

[SHARPY@localhost httptunnel-3.0.5]$ ./htc
./htc: the destination of the tunnel must be specified.
./htc: try './htc --help' for help.

The Binary compiled within the directory and i was able to execute and use it without installing it.

All in all it took about 5 minutes total from download to working binary, a fast fun and simple experience.

That concludes my Vanilla compiles, See you next time.