Tuesday, December 01, 2009
I Don't Care Where You've Been
Here is my current guess at the chords and lyrics for this song. If you find better chords, let me know.
Monday, November 23, 2009
Friday, November 13, 2009
Cannot retrieve metalink for repository: fedora. Please verify its path and try again
If you get this error, and you were running rawhide, do not worry. Just edit your /etc/yum.repos.d/fedora.repo file (again?) and change it from enabled=1 back to enabled=0. During the recent release of Fedora, yum has re-enabled your fedora.repo that you had previous disabled.
As of this blog post, it was the Fedora 12 release that did this again. The Fedora 11 release did the same thing. And, no, Debian Sid does not do this to you. I have been on Debian Sid for years, and it has never enable any repos without at least prompting me first.
The folks on #fedora or #fedora-qa will not believe you though. They will taunt you with phrases like, "normal updates for thousands of people are working just fine", or "there are thousands and thousands of people who had their repo files updated, and they continue to get updates". But don't be discouraged by their "talk to the hand" attitude. Just edit your fedora.repo and set enabled back to 0, and move on with your life, and join me ... I am not one of the thousands and thousands of people who have never had a problem with updating a linux box.
You would not be on this page if your search engine had not led you here. I can tell from the referrers to this page. So I know you are just like me, just some idiot who is having problems udating their fedora rawhide box. We are walking together in this way. We are alike. Do not let the folks in the Linux community convince you that you are the only one on earth who has ever had a problem using their distro.
Note: the root cause of the error "Cannot retrieve metalink for repository: fedora. Please verify its path and try again" seems to be some kind of dns issue see this bug report. Again, I did not get this error again after re-disabling the fedora.repo and continued using rawhide.
As of this blog post, it was the Fedora 12 release that did this again. The Fedora 11 release did the same thing. And, no, Debian Sid does not do this to you. I have been on Debian Sid for years, and it has never enable any repos without at least prompting me first.
The folks on #fedora or #fedora-qa will not believe you though. They will taunt you with phrases like, "normal updates for thousands of people are working just fine", or "there are thousands and thousands of people who had their repo files updated, and they continue to get updates". But don't be discouraged by their "talk to the hand" attitude. Just edit your fedora.repo and set enabled back to 0, and move on with your life, and join me ... I am not one of the thousands and thousands of people who have never had a problem with updating a linux box.
You would not be on this page if your search engine had not led you here. I can tell from the referrers to this page. So I know you are just like me, just some idiot who is having problems udating their fedora rawhide box. We are walking together in this way. We are alike. Do not let the folks in the Linux community convince you that you are the only one on earth who has ever had a problem using their distro.
Note: the root cause of the error "Cannot retrieve metalink for repository: fedora. Please verify its path and try again" seems to be some kind of dns issue see this bug report. Again, I did not get this error again after re-disabling the fedora.repo and continued using rawhide.
Tuesday, November 10, 2009
Don Fransisco
If you have never heard his songs, start now:
Here is a link to the lyrics and chords. Go learn them.
In Him.
Here is a link to the lyrics and chords. Go learn them.
In Him.
Tuesday, October 06, 2009
Wednesday, September 30, 2009
The Eclipse executable launcher was unable to locate its companion shared library
Do not worry. Here is the solution to your problem:1. If you are a real developer just execute the following commands:
$ pwdNow you are done. The problem is fixed.
/cygdrive/c/galileo/eclipse
$ find plugins/ -name \*.dll
plugins/org.eclipse.equinox.launcher.win32.win32.x86_1.0.200.v20090519/eclipse_1206.dll
$ chmod 0755 plugins/org.eclipse.equinox.launcher.win32.win32.x86_1.0.200.v20090519/eclipse_1206.dll
2. If you have never done development from the command-line, and you have not gone to boot camp to learn the new secrets for Vista this year, or whatever sad, proprietary jail cell you are in, then you will need to use a GUI to find the dll named above somewhere down in the eclipse/plugins directory, and give yourself execute permissions to it, and your problem will be fixed. The shortened, but still long, complicated list of clicks and steps probably goes something like ...
-1. Stop crying and feeling sorry for yourself. As a windows user, you are simply a second class citizen, so just buck up and deal with it.Hope that helps.
0. find the "eclipse/plugins/org.eclipse.equinox.launcher.win32.win32.x86_1.0.200.v20090519/eclipse_1206.dll" using the Explorer ...
1. Right-click the file and select Properties.
2. Click on the Security tab.
3. Click Advanced in the lower right.
4. In the Advanced Security Settings window that pops up, click on the Owner tab.
5. Click Edit.
6. Click Other users or groups.
7. Click Advanced in the lower left corner.
8. Click Find Now.
9. Scroll through the results and double-click on your current user account.
10. Click OK to all of the remaining windows except the first Properties window.
11. Select your user account from the list up top and click Edit.
12. Select your user account from the list up top again and then in the pane below, check Full control under Allow, or as much control as you need.
13. You’ll get a security warning, click Yes.
14. On some files that are essential to Windows, you’ll get a “Unable to save permission changes… access is denied” warning and there’s nothing that you can do about it to the best of my knowledge.
15. Consider using something other than Windows.
Tuesday, September 29, 2009
Sunday, August 30, 2009
Lana
Whose battle with cancer has been long
But all through this terrible illness
Her faith in God remains strong
To follow Christ is the only way she knew
And this faith has given her strength
To survive the trials she is going through
would have given up in dispair
we'd quit saying our prayers and tell outselves
Why pray? God just doesn't care
God knows that she has run a good race
He will send angels to guide her into his heavenly kingdom
And she will see Jesus face to face
Janet E. Salamone
August 28, 2009
Thursday, August 27, 2009
Wade in the Water (remix)
Finally got around to making a video with a new version of this song on the uke ...* Here are some chords and lyrics I have been using.
* For the previous free mp3 versions of this song with the girls singing along go here.
Enjoy.
* For the previous free mp3 versions of this song with the girls singing along go here.
Enjoy.
Tuesday, August 25, 2009
Thursday, August 06, 2009
Running rawhide, and having a problem updating today?
Symptom:
Hope that helps.
Symptom:
Error Downloading Packages:Another symptom:
kernel-PAE-2.6.31-0.125.rc5.git2.fc12.i686: failure: Packages/kernel-PAE-2.6.31-0.125.rc5.git2.fc12.i686.rpm from rawhide: (256, 'No more mirrors to try.')
http://archive.linux.duke.edu/pub/fedora/linux/development/i386/os/Packages/kernel-PAE-2.6.31-0.125.rc5.git2.fc12.i686.rpm: [Errno 14] HTTP Error 200 : http://archive.linux.duke.edu/pub/fedora/linux/development/i386/os/Packages/kernel-PAE-2.6.31-0.125.rc5.git2.fc12.i686.rpmDo not worry. Just update the python-urlgrabber package: ‘yum upgrade python-urlgrabber’.
Trying other mirror.
Hope that helps.
Friday, July 31, 2009
Friendship Blossoms
from the trials of our daily walk-and the nettles of each day.
But there's a need, yet deeper still, a very human element;
a need for love, for warmth and strength, a sharing of content.

I think some seeds lay dormant, 'til he molded friends to share.
That day the seeds awakened, took root, and sprouted high ...
as the friendships blossomed-God looked down through His sky,
As He looked, He whispered soft, "tis good-this blossom fair"
He stooped and picked a friendship flower and blew it on the air.
Like dandelions, they scattered, and where'ere a seed touched down
eventually, a friendship grew, in that garden of renown.

and send them winging on the breeze ...
to fertile soil in someone's heart ... and to blossom ... He is pleased.
If we took the time each day, with care, to plant a seed ...
imagine all the friendship flowers would blossom and would lead ...

in more hearts, friendship would be;
then hate and greed would vanish, for all eternity.
It truly is a gift from God, to have a friend to share,
the glories of the moments ... as well as all our cares.
by Dot Chadwick (written in 1967)
Wednesday, July 29, 2009
The Bottom Line
I'm at the bottom line of all my needsby Kara.
I'm blowing at the end of my reed
All of my wants have past away
now all I want is LOVE!
Now tell me when I'm in a situation
or a problem bigger than that
I'll turn my ways around
You help me I help you
We all stick together
at the bottom line!
For more of Kara's poems ... visit Kara's Colors
Monday, July 20, 2009
selecting duplicate rows
Ever wondered how to select only rows that have some duplicate from a field? Well, here is one way that worked pretty well:
select duplicate_column from table_with_duplicates whereHope that helps someone.
(
select count(a.duplicate_column) from table_with_duplicates a
where a.duplicate_column = table_with_duplicates.duplicate_column
) > 1
group by duplicate_column
Monday, July 13, 2009
Baptism and Summer fun ...
We found a turtle ...
What are you talking about?
Under a shroom ...
Grin :-)
Not ashamed.
Snack time ...
Getting ready ...
Baptized ...
Getting ready ...
Baptized ...
On the slide ...
Woah! ... (click to enlarge)
Thursday, July 09, 2009
Fedora Rawhide ... cannot login. Symptoms and solution.
Here is what was happening, and how I fixed it. First of all, I had to reboot into "linux single" just so that I could get to root and read the log files. If you do not know what "linux single" is, email me, and I'll let you know.
Anyway, whenever I tried to login using the normal gdm interface, these messages appeared in /var/log/secure:
Jul 9 09:03:10 lost pam: gdm-fingerprint[930]: PAM unable to dlopen(/lib/security/pam_fprintd.so): /lib/security/pam_fprintd.so: cannot open shared object file: No such file or directory
Jul 9 09:03:10 lost pam: gdm-fingerprint[930]: PAM adding faulty module: /lib/security/pam_fprintd.so
Jul 9 09:03:21 lost pam: gdm-password[991]: gkr-pam: couldn't run gnome-keyring-daemon: Permission denied
Jul 9 09:03:21 lost pam: gdm-password[929]: gkr-pam: gnome-keyring-daemon didn't start properly properly
Jul 9 09:03:21 lost pam: gdm-password[929]: pam_unix(gdm-password:session): session opened for user geek by (uid=0)
Jul 9 09:03:22 lost pam: gdm-password[929]: pam_unix(gdm-password:session): session closed for user geek
Then when I tried to login using the console, these messages appeared in /var/log/secure:
Jul 9 09:03:30 lost login: PAM unable to dlopen(/lib/security/pam_fprintd.so): /lib/security/pam_fprintd.so: cannot open shared object file: No such file or directory
Jul 9 09:03:30 lost login: PAM adding faulty module: /lib/security/pam_fprintd.so
Jul 9 09:03:34 lost login: pam_unix(login:session): session opened for user root by LOGIN(uid=0)
Jul 9 09:03:34 lost login: ROOT LOGIN ON tty2
Jul 9 09:03:34 lost login: pam_unix(login:session): session closed for user root
Well this made sense after seeing the following:
[root@lost ~]# ls -l /lib/security/pam_fprintd.so
lrwxrwxrwx. 1 root root 20 2009-07-09 10:59 /lib/security/pam_fprintd.so -> pam_fprintd.so.0.0.0
[root@lost ~]# ls -l /lib/security/pam_fprintd.so.0.0.0
ls: cannot access /lib/security/pam_fprintd.so.0.0.0: No such file or directory
I'm not sure why the package called fprintd-pam.i586 installs a file that links to "No such file or directory". But removing fprintd-pam.i586 and gdm-fingerprint did not help.
The quickest solution for this issue was to disable selinux. Surely there is a better solution. If you know what that is, let us know.
Anyway, whenever I tried to login using the normal gdm interface, these messages appeared in /var/log/secure:
Jul 9 09:03:10 lost pam: gdm-fingerprint[930]: PAM unable to dlopen(/lib/security/pam_fprintd.so): /lib/security/pam_fprintd.so: cannot open shared object file: No such file or directory
Jul 9 09:03:10 lost pam: gdm-fingerprint[930]: PAM adding faulty module: /lib/security/pam_fprintd.so
Jul 9 09:03:21 lost pam: gdm-password[991]: gkr-pam: couldn't run gnome-keyring-daemon: Permission denied
Jul 9 09:03:21 lost pam: gdm-password[929]: gkr-pam: gnome-keyring-daemon didn't start properly properly
Jul 9 09:03:21 lost pam: gdm-password[929]: pam_unix(gdm-password:session): session opened for user geek by (uid=0)
Jul 9 09:03:22 lost pam: gdm-password[929]: pam_unix(gdm-password:session): session closed for user geek
Then when I tried to login using the console, these messages appeared in /var/log/secure:
Jul 9 09:03:30 lost login: PAM unable to dlopen(/lib/security/pam_fprintd.so): /lib/security/pam_fprintd.so: cannot open shared object file: No such file or directory
Jul 9 09:03:30 lost login: PAM adding faulty module: /lib/security/pam_fprintd.so
Jul 9 09:03:34 lost login: pam_unix(login:session): session opened for user root by LOGIN(uid=0)
Jul 9 09:03:34 lost login: ROOT LOGIN ON tty2
Jul 9 09:03:34 lost login: pam_unix(login:session): session closed for user root
Well this made sense after seeing the following:
[root@lost ~]# ls -l /lib/security/pam_fprintd.so
lrwxrwxrwx. 1 root root 20 2009-07-09 10:59 /lib/security/pam_fprintd.so -> pam_fprintd.so.0.0.0
[root@lost ~]# ls -l /lib/security/pam_fprintd.so.0.0.0
ls: cannot access /lib/security/pam_fprintd.so.0.0.0: No such file or directory
I'm not sure why the package called fprintd-pam.i586 installs a file that links to "No such file or directory". But removing fprintd-pam.i586 and gdm-fingerprint did not help.
The quickest solution for this issue was to disable selinux. Surely there is a better solution. If you know what that is, let us know.
Thursday, June 04, 2009
Fedora 11: yum hangs on 'Setting up Package Sacks'
NOTE: this post was originally written after seeing this problem in rawhide. The problem persisted into Fedora 11, but all the notes below are for a rawhide configuration. The fix below works for the fedora.repo also.
If you are trying Fedora 11 and yum hangs showing the following output:
Note, all this assumes that you set up your proxy as follows:
Then again, you may enjoy having some extra time while you stare at yum hanging at 'Setting up Package Sacks' until it times out, I sure did ... it gave me enough time to write the following rant.
Remember ... this was the Fedora 11 preview, so you do not want to enable the normal repositories. This is a "feature bug" in my opinion. Doing an update should not change my enabled repositories without prompting me. I feel like this is a bug because I have used Debian (sid) for years, and I have been using Redhat/Fedora for just as long, but I have never had this problem with Debian. Flame away.
Hope that helps.
UPDATE: Although this blog entry was for "Fedora 11 - preview" the solutions suggested here, as the anonymous comment below suggests, may also apply to Fedora 11 which has now been released.
If you are trying Fedora 11 and yum hangs showing the following output:
# yum -v updateDo not fear. There are (at least) two reasons why you can see this issue. First, the problem may just be an intersection between your proxy's configuration and the default yum configuration. If you are behind a proxy, just edit the file /etc/yum.repos.d/fedora-rawhide.repo and change the default "mirrorlist" entry to use http instead of https as follows:
Config time: 0.045
Yum Version: 3.2.22
Setting up Package Sacks
_
mirrorlist=http://mirrors.fedoraproject.org/metalink?repo=rawhide&arch=i386Of course, you will need to leave the "arch" as x86_64 if you are installing on a 64bit machine. The default https that fedora has chosen will not work with many "transparent" proxy setups, so just change it to http, and you should be fine.
enabled=1
Note, all this assumes that you set up your proxy as follows:
# export http_proxy=http://my-semi-xparent-proxy.com:8080And when you do run a yum update, run it like this:
yum -v --enablerepo=rawhide updateAlternatively you can edit the /etc/yum.conf file and add a line like this
proxy=http://my_proxy.com:port/Which brings us to the second easy way to get yourself stuck staring at 'Setting up Package Sacks'. This came up when folks were updating Fedora 11 - preview ... that is, do not run it simply as "yum update" like I did, because it will look as though it does the update just fine, but it will break yum. Doing a simple "yum update" without enabling rawhide will enable the base fedora.repo and the fedora-updates.repo, which will also cause yum to hang at 'Setting up Package Sacks' again with the new "https" in the newly updated "fedora.repo".
Then again, you may enjoy having some extra time while you stare at yum hanging at 'Setting up Package Sacks' until it times out, I sure did ... it gave me enough time to write the following rant.
Remember ... this was the Fedora 11 preview, so you do not want to enable the normal repositories. This is a "feature bug" in my opinion. Doing an update should not change my enabled repositories without prompting me. I feel like this is a bug because I have used Debian (sid) for years, and I have been using Redhat/Fedora for just as long, but I have never had this problem with Debian. Flame away.
Hope that helps.
UPDATE: Although this blog entry was for "Fedora 11 - preview" the solutions suggested here, as the anonymous comment below suggests, may also apply to Fedora 11 which has now been released.
Sunday, May 31, 2009
Friday, May 01, 2009
All I Need Is God
Looks like my blue skies fade to gray
Looks like my pasture's gone away, but
I still don't need your golden cherubim
All I need is God
All I need is God
In the beginning
All I need is God
To survive
All I need is God
To help me all I need
By Kara
Thursday, April 30, 2009
Error: 'CREATE VIEW' must be the first statement in a query batch
Have you ever gotten this error?
You will get the error above, as I did, when executing the CREATE from within SQuirreL SQL, so apparently SQuirreL is attempting to do some 'innocent' things before the CREATE statement. Wrapping the CREATE in an exec forces SQuirreL to put the CREATE statement first in a separate execution plan.
Hope that helps you.
Error: 'CREATE VIEW' must be the first statement in a query batch.Well dont worry, here is how you may solve this issue: Just wrap your query with exec(''). For example, lets say your view is defined as
SQLState: S0001
ErrorCode: 111
CREATE VIEW theView ASWell then just change your call as follows:
SELECT tableA.id + '_' tableA.name AS ID_NAME,
tableB.* FROM tableA a
INNER JOIN tableB b ON a.a_id = b.b_Id
exec('CREATE VIEW theView AS
SELECT tableA.id + ''_'' tableA.name AS ID_NAME,
tableB.* FROM tableA a
INNER JOIN tableB b ON a.a_id = b.b_Id')Notice that single quotes origninally in my CREATE statement are escaped as two consecutive single quotes after it is wrapped in the call to exec('').You will get the error above, as I did, when executing the CREATE from within SQuirreL SQL, so apparently SQuirreL is attempting to do some 'innocent' things before the CREATE statement. Wrapping the CREATE in an exec forces SQuirreL to put the CREATE statement first in a separate execution plan.
Hope that helps you.
Sunday, April 26, 2009
Fall Leaves
See those fall leaves falling from those fall trees? See the leaves falling? They are yellow, green, purple, and brown. Don't frown. Turn your frown upside down. Don't be a clown, 'cuz if your singing, you'll be slinging your love. See the fall leaves falling? Are you stalling? I think not, 'cuz it's getting alot better than I thought. Good night!by Kara Singleton
Saturday, April 18, 2009
Beach time ...
First, some watermelon ...
What is that?
Let's go to the beach!
Ooooo - kay ...
Are we there yet?
We are here!
Big sisters ...
Sea shells ...
Sunsets ...
Yay!

What is that?

Let's go to the beach!

Ooooo - kay ...

Are we there yet?

We are here!

Big sisters ...

Sea shells ...

Sunsets ...

Yay!
Friday, April 17, 2009
deploying with sftp or scp using ant ... Could not load a dependent class com/jcraft/jsch/UserInfo
Have you ever gotten an error like this?
You will find a page here that is supposed to help you, but well, let's just say that technical people have a problem communicating sometimes.
So below, I will show you how I solved this problem by downloading the Java Secure Channel jar from here, and putting that jar in the $ANT_HOME/lib directory
So, the procedure above shows:
1. the ant build target I used with the scp task
2. the failure that will occur without the use of the Java Secure Channel jar
3. copying the jar to your $ANT_HOME/lib directory
4. the successful transfer of files using sftp
This has been tested with ant 1.6.5 and 1.7.1, although you will get the following error if you use sftp="true" with ant 1.6.5:
If you simply remove the sftp="true" attribute from the scp task, then the file tranfer works fine under ant 1.6.5 using the build target as shown above.
Hope that helps.
Could not load a dependent class com/jcraft/jsch/UserInfoYou are not alone.
You will find a page here that is supposed to help you, but well, let's just say that technical people have a problem communicating sometimes.
So below, I will show you how I solved this problem by downloading the Java Secure Channel jar from here, and putting that jar in the $ANT_HOME/lib directory
$ cat build.xml
<project name="Life" basedir=".">
<target name="deploy">
<scp todir="${user}:${pass}@remoteBox.com:." sftp="true" >
<fileset dir=".">
<include name="**/foo.*"/>
</fileset>
</scp>
</target>
</project>
$ ant -Duser=geek -Dpass=g33k deploy
Buildfile: build.xml
deploy:
BUILD FAILED
build.xml:4: Problem: failed to create task or type scp
Cause: Could not load a dependent class com/jcraft/jsch/UserInfo
It is not enough to have Ant's optional JARs
you need the JAR files that the optional tasks depend upon.
Ant's optional task dependencies are listed in the manual.
Action: Determine what extra JAR files are needed, and place them in one of:
-$ANT_HOME\lib
-$HOME\.ant\lib
-a directory added on the command line with the -lib argument
Do not panic, this is a common problem.
The commonest cause is a missing JAR.
This is not a bug; it is a configuration problem
Total time: 0 seconds
$ cp jsch-0.1.41.jar $ANT_HOME/lib/.
$ ant -Duser=geek -Dpass=g33k deploy
Buildfile: build.xml
deploy:
[scp] Connecting to remoteBox.com:22
[scp] done.
BUILD SUCCESSFUL
Total time: 2 seconds
So, the procedure above shows:
1. the ant build target I used with the scp task
2. the failure that will occur without the use of the Java Secure Channel jar
3. copying the jar to your $ANT_HOME/lib directory
4. the successful transfer of files using sftp
This has been tested with ant 1.6.5 and 1.7.1, although you will get the following error if you use sftp="true" with ant 1.6.5:
$ ant -Duser=geek -Dpass=g33k deploy
Buildfile: build.xml
deploy:
BUILD FAILED
build.xml:4: Thetype doesn't support the "sftp" attribute.
Total time: 0 seconds
If you simply remove the sftp="true" attribute from the scp task, then the file tranfer works fine under ant 1.6.5 using the build target as shown above.
Hope that helps.
Subscribe to:
Posts (Atom)



